RE: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint
- 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 :)
Date: Sun, 1 Mar 2009 07:31:23 -0500
Subject: Re: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprintHello, Roy. On Saturday, February 28, 2009, at 11:03:51 PM, you
> I would even go so far as to say What right do they have to beMillions of years of evolution?
> reluctant to accept change?
> Every change requested and incorporated into the system is oneThis is simply not true. Many developers, if not most, have
> 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.
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
Play the game as often as you want. The first way never loses.
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
- Hello, Robert. On Saturday, March 7, 2009, at 1:51:27 PM, you
> What seemed odd to me about your game is that it seemed to involveMaybe next game, with that point. :)
> no decision making during play. I had been expecting to see some kind of
> evaluation and some kind of decision-making about making changes.
Attend our CSM Plus Course!
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