--- In email@example.com
, Ron Jeffries
> On Friday, August 1, 2003, at 1:20:32 PM, nasapatrick wrote:
> > Okay, so I have a backlog item like -- Derive the universe, use
> > of paper as necessary --
> > Which do you do?
> > - Break it into many product backlog items?
> > - Choose a sprint goal to implement only part of a backlog item?
> I'd break it up, make it smaller. One advantage to this is that
lots of the
> subparts (make sure universe supports life) are much more
> some are less so (make lizards have hair).
Yes, absolutely. Break it up AND choose slim sprint goals.
When the users are asked to rank the more granular features, you
might be amazed by the things they think are low priority.
For example, when you take a project where priority rankings have
been done inside IT (because the initial requirement was too high
level - "derive the Universe"), and rescue it with Scrum, you take it
back to the users and say - let's break it down and prioritise. Then
the things that developers thought were urgent (because they are sexy
and fun to do, or because they look good on a resume, or because they
made incorrect assumptions about the business) - these sometimes end
up at the bottom of the user's list! We've gotten used to automating
just to automate, whereas the guys footing the bill, when given the
chance, can say: "at that price, I'll keep doing it with Post-It
The net result is: you can get IMPORTANT functionality out the door
and working much faster than you could complete the whole original
requirement. And eventually, users may drop the insignificant ones
right off the backlog when they see that their return does not
justify development costs.
And, this is not "just" a newbie question. It is important because it
hilights the essential cultural shift required by Scrum: From
delivering the Universe because it was naively asked for, to helping
Customers discover what they *really* want, and delivering that as
quickly as possible.
The heavy processes have brainwashed some developers (and managers)
into accepting the idea that the project is a success if our delivery
covers everything the user asked for - whether it actually meets
their needs or not. I think the Agile movement is trying to redefine
what successful development looks like. Success in development =
demonstrable value for the Customer. As evaluated BY THE CUSTOMER
(hence, active stakeholder participation). That's it! (Remembering
that ease of maintenance is also of value to the Customer - and we
must educate them in this).