Loading ...
Sorry, an error occurred while loading the content.

50232Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Adam Sroka
    Feb 2, 2011
    • 0 Attachment
      On Wed, Feb 2, 2011 at 5:46 PM, Charles Bradley - Scrum Coach CSM PSM
      I <chuck-lists2@...> wrote:
      >
      >
      >
      > Some good points Adam.  We view frameworks a bit differently(but not too much), but that's not the point of this discussion, and I certainly don't want to get sidetracked on that.  lol.
      >
      > > Why should the customer pay for a poor technical decision you made somewhere up the line?
      >
      > In the scenario I described, I made it clear that one can assume it was a good technical decision.
      >

      I think one must assume that it is a poor technical decision given
      that you had to completely reverse it in the midst of development.

      If you had used a crystal ball to see where you were going you would
      have only chosen the latter framework. Most framework builders assume
      that you have such a crystal ball, in part because they thought they
      were using one to write the framework.

      > I'm not asking anyone to accept a poor technical decision, and I'm also not thinking that the PO is the best authority on whether a technical decision is poor or not.  I do think, though, they are the best authority in Scrum on whether a Product Backlog item provides the intended value or not.
      >

      He must be the authority on what has value per se. That is what
      "Product Owner" means in Scrum. In practice, however, he needs to have
      a lot of conversations to validate these decisions.

      He doesn't care about technical decisions and I did not intend to
      imply that he did. He should be judging what you present him based on
      the value to the customers/users. Technical decisions are meaningless
      in this context.

      He does, however, care about cost. Which means that if you estimate a
      big cost for a small value based on some technical thing the most
      reasonable thing for him to do is de-prioritize it accordingly.
    • Show all 25 messages in this topic