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

1342RE: [scrumdevelopment] Re: Planning a product release

Expand Messages
  • Mike Cohn
    May 1, 2003
    • 0 Attachment
      First, sorry for the greatly delayed response. I've been buried and haven't
      had time to look at the chapter. Good point. I corrected the text (I'd left
      out a couple of words.)

      No, I've never really tried averaging the numbers. I'll sometimes look at
      both as a sanity check but I almost always use the square root of the sum of
      the squared differences. There's more of a mathematical basis for that and
      I've found that estimating is much easier when developers are given the
      freedom to estimating stories and tasks in a range ("3-5 days"), just like
      we'd like to be able to tell Product Owners a range ("4-6 sprints").

      Thanks again for finding and pointing out my goof.


      -----Original Message-----
      From: Dan Brown [mailto:kid_danomite@...]
      Sent: Wednesday, April 16, 2003 11:30 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Planning a product release

      Mike & Ken:

      Thanks! That makes a lot of sense, but it will take some practice to
      decompose our stories into 3-4 day chunks instead of diving into the
      design of a big task more quickly.

      Mike - I hope the answer to the XXXXXXXX on c 7, p 48 comes out the
      way you want it!

      One final thing - I did notice a potential error on c9, p74, where
      the text & the table are inconsistent about using the square root of
      the sum of the squares (probably what you want) or the square root of
      the sum. The other thing you may want to mention at the end of this
      page (74) when comparing simple 50% buffers to square root sum of the
      squares is that if you have a large number of tasks, the 50% buffer
      grows much more quickly than the square root of the sum of squares
      (i.e. for a very large program, this may represent very little
      difference from the 50% case). Have you ever tried something like
      taking the an average of the sum of the 50% & the sum of the 90% or
      if you want to stick with the square of the difference approximating
      the variance of the task you could even set confidence bounds on the
      project by estimating the average of the sum(50%) & sum(90%) plus or
      minus the square root of the sum of the squares of the differences.
      This would have the added benefit of telling you if your confidence
      bounds are, perhaps, longer than 1 Sprint-length.


      --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      > John--
      > The image on the page is from a simplified version of the
      spreadsheet I was
      > using at the time. There's a better version of the actual
      spreadsheet at
      > http://www.mountaingoatsoftware.com/resources.html. In that one
      you'll see
      > where I have columns for 50% and 90%. Developers have such an
      easier time
      > saying "that will take 4 or 5 days" instead of "that will take 4
      days" that
      > I have the team formalize what they mean by their low and high
      estimates and
      > then give both. Giving two estimates seems like twice the work of
      giving one
      > estimate but it's actually much easier. Even better--the two
      estimates are
      > more expressive so I can use them to size buffers early on.
      > When a sprint is ongoing and we're tracking sprint backlog (as
      shown at
      > http://www.mountaingoatsoftware.com/scrum/sprintbacklog.html) we
      just track
      > a simple 50% estimate of the time left to completion. The work is
      already in
      > the sprint at that point so you don't have any real control over
      the buffer
      > (it's already sized) so there's no point in tracking 50% and 90%
      numbers for
      > items in the sprint backlog.
      > I'm glad you enjoyed the user stories drafts. I'd appreciate any
      > feedback you have on it as I continue with it.
      > --Mike
      > -----Original Message-----
      > From: gilmanj_2000 [mailto:jpgilman@m...]
      > Sent: Wednesday, April 16, 2003 5:34 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] Re: Planning a product release
      > Mike, thanks for your response to Dan and I really enjoyed what
      > you've written so far on your user stories book. Look forward to
      > it's completion.
      > Here is my question. I understand the importance of including a
      > proper buffer in the project itself. But, when estimating work in
      > the product backlog e.g.
      > http://www.mountaingoatsoftware.com/scrum/productbacklog.html, do
      > your individual estimates include a buffer based on your 50% and
      > task estimates? Or are these your 50% estimates?
      > Thanks, John
      > --- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
      > wrote:
      > > Dan--
      > > Dan--
      > >
      > > I've had a number of situations where I need to produce a
      > I can
      > > commit to but only have the beginnings of the requirements/tasks.
      > Here's
      > > what I do:
      > >
      > > I try to specify the requirements as XP user stories. I find
      > to be the
      > > best way to capture requirements for just about any agile
      > This way
      > > they are not too small, not too big, but typically "just right"
      > > estimating. Stories also avoid problems with task-estimating
      > many of
      > > the tasks are highly similar, which leads to a systematic error
      > the
      > > estimate (one mistake trickles through many estimates).
      > >
      > > For each story I estimate it at both 50% and 90% levels of
      > confidence. My
      > > 50% estimate is one I think I'll make half the time--if I coded
      > that story
      > > 20 times, 10 would finish ahead of this and 10 after. It has no
      > padding in
      > > it. The 90% estimate assumes the task is on the hard end of the
      > > spectrum--it's not a "worst case" scenario because no one gets
      > over by a
      > > bus or anything like that in this estimate.
      > >
      > > My project schedule is then the sum of the 50% unbuffered
      > plus
      > > some buffer which is determined by looking at the differences
      > between the
      > > 50% and 90% estimates: take the square root of the sum of the
      > differences
      > > between each 50% and 90% estimate and that will give you a
      > reasonable
      > > project buffer. The approach is covered well in
      Leach's "Critical
      > Chain
      > > Project Management."
      > >
      > > This gives me a buffered schedule that takes into account overall
      > > uncertainty (but isn't as huge as one from adding all the
      > > uncertainty, which would be wrong). I then round it up into a
      > number of
      > > sprints. If the team is new to Scrum I may add one more sprint
      > (month) to
      > > the end and use that as a "stabilization sprint" meaning the team
      > will need
      > > that extra month to work out any last bugs.
      > >
      > > I've been very successful with this in estimating and committing
      > projects
      > > out about 9 months into the future. (I haven't failed with it at
      > longer
      > > ones; I've just been able to avoid longer commitments!)
      > >
      > > I realize I didn't have time to type in many details (it's a busy
      > month!)
      > > but I have written more about it on www.userstories.com if you're
      > > interested. If so, go to http://www.userstories.com/download.php
      > and take a
      > > look at "Principles of Estimating," "Estimating User
      Stories," "Why
      > Plans Go
      > > Wrong," and "Planning a Release."
      > >
      > > --Mike
      > >
      > > -----Original Message-----
      > > From: Dan Brown [mailto:kid_danomite@y...]
      > > Sent: Friday, April 11, 2003 9:56 PM
      > > To: scrumdevelopment@yahoogroups.com
      > > Subject: [scrumdevelopment] Planning a product release
      > >
      > > I could use some advice from the group.
      > >
      > > Our group adapted Scrum about 5 months ago in the middle of a
      > project
      > > that was failing. We since extended this to a couple other
      > projects
      > > that were failing and it has worked wonders and I have grown in
      > > experience leading some of these projects. What no one on our
      > > has any experience with is STARTING a product release with
      > >
      > > I read a recommendation several (hundred?) messages ago that
      > > advocated something like a planning sprint to bring teams into
      > > Scrum. Our team is already bought into Scrum, and would like to
      > > evolve our design during many sprints with several Scrum teams
      > > working in parallel after which we will deliver our product.
      > > However, we are having a hard time telling management that we
      > be
      > > able to deliver a product with XY&Z in it on date D, without
      > > doing enough of a design analysis on the feature list to feel
      > we
      > > really understand the complexities to give a solid estimate. In
      > our
      > > industry, estimates are required because our business & our
      > customers
      > > need some planning to bring together many elements, of which the
      > > software we will deliver is just one.
      > >
      > > I'm sure Scrum must be used places where these types of pre-
      > > estimates must be given and contracted upon. What is done in
      > > case? Is decomposing the user stories into what we feel are
      > > long product backlog bits in a planning sprint sufficient and
      > > recommended? Somehow I have a sinking feeling (clinging to my
      > false
      > > sense of security in waterfall) that this may just get me fired.
      > >
      > > Thanks so very much for any advice,
      > >
      > > Dan
      > >
      > >
      > >
      > >
      > > To Post a message, send it to: scrumdevelopment@e...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@e...
      > >
      > > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      > To Post a message, send it to: scrumdevelopment@e...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@e...
      > Your use of Yahoo! Groups is subject to

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • Show all 13 messages in this topic