1342RE: [scrumdevelopment] Re: Planning a product release
- May 1, 2003Dan--
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.
From: Dan Brown [mailto:kid_danomite@...]
Sent: Wednesday, April 16, 2003 11:30 PM
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 email@example.com, "Mike Cohn" <mike@m...>
> John--spreadsheet I was
> The image on the page is from a simplified version of the
> using at the time. There's a better version of the actualspreadsheet at
> http://www.mountaingoatsoftware.com/resources.html. In that oneyou'll see
> where I have columns for 50% and 90%. Developers have such aneasier time
> saying "that will take 4 or 5 days" instead of "that will take 4days" that
> I have the team formalize what they mean by their low and highestimates and
> then give both. Giving two estimates seems like twice the work ofgiving one
> estimate but it's actually much easier. Even better--the twoestimates are
> more expressive so I can use them to size buffers early on.shown at
> When a sprint is ongoing and we're tracking sprint backlog (as
> a simple 50% estimate of the time left to completion. The work isalready in
> the sprint at that point so you don't have any real control overthe buffer
> (it's already sized) so there's no point in tracking 50% and 90%numbers for
> items in the sprint backlog.specific
> I'm glad you enjoyed the user stories drafts. I'd appreciate any
> feedback you have on it as I continue with it.90%
> -----Original Message-----
> From: gilmanj_2000 [mailto:jpgilman@m...]
> Sent: Wednesday, April 16, 2003 5:34 PM
> To: firstname.lastname@example.org
> 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?deadline
> Thanks, John
> --- In email@example.com, "Mike Cohn" <mike@m...>
> > Dan--
> > Dan--
> > I've had a number of situations where I need to produce a
> I canthose
> > commit to but only have the beginnings of the requirements/tasks.
> > what I do:
> > I try to specify the requirements as XP user stories. I find
> to be theproject.
> > best way to capture requirements for just about any agile
> This wayfor
> > they are not too small, not too big, but typically "just right"
> > estimating. Stories also avoid problems with task-estimatingwhere
> many ofin
> > the tasks are highly similar, which leads to a systematic error
> > 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 aestimates
> > bus or anything like that in this estimate.
> > My project schedule is then the sum of the 50% unbuffered
> plusLeach's "Critical
> > 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
> > between each 50% and 90% estimate and that will give you a
> > project buffer. The approach is covered well in
> > 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 ato
> 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
> projectsStories," "Why
> > out about 9 months into the future. (I haven't failed with it at
> > 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
> > 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
> Plans Goteam
> > Wrong," and "Planning a Release."
> > --Mike
> > -----Original Message-----
> > From: Dan Brown [mailto:kid_danomite@y...]
> > Sent: Friday, April 11, 2003 9:56 PM
> > To: firstname.lastname@example.org
> > 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
> > that was failing. We since extended this to a couple other
> > 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 withScrum.
> > 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
> > 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 feellike
> > really understand the complexities to give a solid estimate. In
> > industry, estimates are required because our business & our
> > 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 inthis
> > case? Is decomposing the user stories into what we feel aremonth-
> > long product backlog bits in a planning sprint sufficient andhttp://docs.yahoo.com/info/terms/
> > recommended? Somehow I have a sinking feeling (clinging to my
> > 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
> To Post a message, send it to: scrumdevelopment@e...
> To Unsubscribe, send a blank message to:
> 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/
- << Previous post in topic Next post in topic >>