Re: More newbie questions...
- --- In email@example.com, Ron Jeffries
> On Friday, August 1, 2003, at 1:20:32 PM, nasapatrick wrote:back
> > Okay, so I have a backlog item like -- Derive the universe, use
> > of paper as necessary --lots of the
> > 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
> subparts (make sure universe supports life) are much moreimportant, and
> 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).
> From: "Christian Knott" <chrisknott@...>Christian:
> With Scrum, we get to show what's been done every 30 days. That means
> that the "alignment smell" gets to be put on view once a month
> instead of, well, never in many other cases.
But in Scrum we also show what is done every day. Remember,
"Daily Build" and "Daily Scrum" are basic Scrum patterns.
A while ago Jeff Sutherland pointed to an article written by
Martin Fowler about continuous integration. All good and dandy.
It is great to have things like Anthill produce automatic builds
and run batches of unit tests. But it is also important for
the Customer to interact with stable versions of the application
and give feedback from hands-on experience on a daily basis.
Also, there are things like Fit and Fitnesse that attempt to
Automate "acceptance testing". Our style is to do this
through "human interaction" -- there are some things that
we feel are best leaving non-automated i.e. where we want humans
In our development we have perhaps hundreds if not thousands
of builds every day, and thousands of check ins and updates,
but we advertise at least one stable build daily for the customers
to play with.
> For the specific problem of fuzzily defined requirements for reports,done.
> I'm with Ron, pretty much. My difference: do something. Anything.
> Guestimate what the report should be, do it quickly, then mark it
Well, "mark it done" might be pushing your luck.
Some customers take it very offensively to "mark things done"
if they are not done. But certainly, getting a report out
for someone to see will start the feedback loops. (Don't forget
to update your daily estimate to completion after some work
and feedback are produced :-)
> The donors/owners will soon start griping, and you can convertTrue.
> their gripes into requirements that go on the product backlog.