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

50234Re: [scrumdevelopment] Refactoring type work in Scrum

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Feb 2 6:33 PM
    • 0 Attachment
      Adam, we don't agree on the framework thing, and I don't care to debate it, so I will concede this line of discussion to you.
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/



      From: Adam Sroka <adam.sroka@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Wed, February 2, 2011 6:59:26 PM
      Subject: Re: [scrumdevelopment] Refactoring type work in Scrum

       

      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