2950RE: [scrumdevelopment] RE: What to do with "loose ends"
- Mar 10, 2004Greg--
A final "move to production" sprint can be dangerous. But, I've used
"stabilization sprints" successfully with new teams for years. The idea
behind these was that during sprints we targeted "friendly first use" as our
quality goal. At any time a sprint's product increment could be given to a
beta site, put on a private-view part of the website, or whatever was
appropriate. During the "stabilization sprint" we took quality from Friendly
First Use to Production Ready. This should mean as little as possible but
often was polishing like making sure manuals were ready and in-sync with
the deliverables, etc. Don't become too reliant on stabilization sprints but
use them as short iterations to polish a release for big-time use.
Additionally--Yes, collect your loose ends into a story and just call it
"tie up some loose ends" or "Fix the low priority bugs we've never paid
attention to". Then time-box it if practical--say you'll spend no more than
80 person-hours this sprint on all the little nagging crud your Product
Owner wants taken care but that on its own (you're right) never makes it to
the top of a priority list.
Author of User Stories Applied for Agile Software Development
From: Greg [mailto:profos9@...]
Sent: Wednesday, March 10, 2004 2:00 PM
Subject: [scrumdevelopment] RE: What to do with "loose ends"
I want to thank everyone for your great responses to
this topic. I've been working with Dennis on
introducing Scrum into our organization and we have
been very pleased with the results thus far.
Before Dennis posted the question on "loose ends" we
thought that it might come down to a simple question
of priority and I guess that it stills does to an
extent. But, one thing that I'm concerned about is
that many of these issues are "rough edges" in (or on)
the product. Individually, they can be easily
overlooked and are of no consequence. However,
collectively, these rough edges add up to a product
that may be perceived as being unfinished or
So, if the "loose ends" are considered as individual
items and prioritized as such they may never be
addressed. Thus it would seem that this is when the
collective nature of these "loose ends" is a problem.
The end result being the product that is unrefined,
unpolished and ready for prime time.
I think Charlie Trainor has a good point about quality
and how those rough edges should be caught prior to
the review. We obviously have some "opportunities"
for improvement there.:) But, in the rush to meet the
goals of the current sprint, how do you balance the
quality issues (that create many of the loose ends)?
I also liked Michael Hirsch's approach to bundling
related ones into a single requirement. That may take
care of a portion of your loose ends. But, what of
the ones that don't bundle well? In a complex product
that list may be significant.
Has anyone just saved these up for a final (move to
production) sprint and tried to resolve as many of
these as can be done during that sprint? Or is that
asking for trouble?
Thanks again for all of your advice.
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Yahoo! Groups Links
- << Previous post in topic Next post in topic >>