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

RE: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint

Expand Messages
  • Roy Morien
    Yes, Ron, a good response to my email. But I was assuming that my comments would be seen within the context of a Scrum development activity, where changes are
    Message 1 of 74 , Mar 1, 2009
    • 0 Attachment
      Yes, Ron, a good response to my email. But I was assuming that my comments would be seen within the context of a Scrum development activity, where changes are accepted, prioritised, estimated, added to the Product Backlog. The impact of this on cost budgets and deadlines is always known under these situations. If the estimated development period of the project, including the new stories, looks likely to be exceeded, then this is known, and communicated. Where there is a fixed deadline, or a fixed budget, then the client (presumably via the Project Owner) must make certain decisions about the likelihood of completing all of the stories within the deadline or within the budget. If the changes are likely to 'blow the budget' then, in the normal and usual scheme of things, they will be evaluated along with everything else as to being implemented. This is different to refusing the change in the first place.
       
      I still say that a change refused (or not implemented) makes the system that much further away from optimal useability and usefulness. But a well considered decision to not implement wll certainly mitigate that impact.
       
      And I did raise a caveat in regard to design thrashing.
       
      But, I'll try to find the time to play your card game :)
       
      Regards,
      Roy Morien  

      To: scrumdevelopment@yahoogroups.com
      From: ronjeffries@...
      Date: Sun, 1 Mar 2009 07:31:23 -0500
      Subject: Re: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint

      Hello, Roy. On Saturday, February 28, 2009, at 11:03:51 PM, you
      wrote:

      > I would even go so far as to say What right do they have to be
      > reluctant to accept change?

      Millions of years of evolution?

      > Every change requested and incorporated into the system is one
      > step closer to a useful and useable system. Every change requested
      > and rejected is one step further away from having a system that is
      > acceptable to the user.

      This is simply not true. Many developers, if not most, have
      encountered conflicting priorities, and drivers who don't know where
      they are going. Quite a few have probably seen more of that than
      they have seen of this continual progress toward good that you seem
      to be imagining here.

      In addition, many if not most projects have a deadline and a budget.
      There is a finite amount of work that can be done before then. Doing
      one thing over and over would mean that at most one thing would be
      done. That would not likely be good.

      I agree that the PO has the right (and duty) to change what she sees
      fit, and that the team needs to "just do it" in some sense. However,
      the results of the project will depend strongly on how well she
      makes her selections.

      Here's a game for you to play. Take a deck of, oh, twenty cards, and
      put the numbers from one to twenty on them. These are the stories
      and their values: number 1 is worth 1, 20 is worth 20.

      We get ten plays and we play the game two ways.

      First way: pick ten cards from the deck with intention to do them,
      maximizing value. Hint (20, 19, 18, ...)

      Second way: Shuffle the deck and draw a card blindly. On a sheet of
      paper, write the number you got. Put the card back in the deck and
      repeat. If you ever get the same number, cross out that number on
      the sheet of paper, and write it again: you just did that story
      over.

      Play the game as often as you want. The first way never loses.

      Ron Jeffries
      www.XProgramming. com
      www.xprogramming. com/blog
      Attend our CSM Plus Course!
      http://hendricksonx p.com/index. php?option= com_eventlist& Itemid=28
      The rules are ways of thinking, not ways to avoid thinking.




      Get what you want at ebay. View photos of singles in your area
    • Ron Jeffries
      Hello, Robert. On Saturday, March 7, 2009, at 1:51:27 PM, you ... Maybe next game, with that point. :) Ron Jeffries www.XProgramming.com
      Message 74 of 74 , Mar 7, 2009
      • 0 Attachment
        Hello, Robert. On Saturday, March 7, 2009, at 1:51:27 PM, you
        wrote:

        > What seemed odd to me about your game is that it seemed to involve
        > no decision making during play. I had been expecting to see some kind of
        > evaluation and some kind of decision-making about making changes.

        Maybe next game, with that point. :)

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Attend our CSM Plus Course!
        http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
        The model that really matters is the one that people have in
        their minds. All other models and documentation exist only to
        get the right model into the right mind at the right time.
        -- Paul Oldfield
      Your message has been successfully submitted and would be delivered to recipients shortly.