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

2950RE: [scrumdevelopment] RE: What to do with "loose ends"

Expand Messages
  • Mike Cohn
    Mar 10, 2004
      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.

      --Mike Cohn
      Author of User Stories Applied for Agile Software Development

      -----Original Message-----
      From: Greg [mailto:profos9@...]
      Sent: Wednesday, March 10, 2004 2:00 PM
      To: scrumdevelopment@yahoogroups.com
      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.

      Any thoughts?

      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
    • Show all 26 messages in this topic