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

Expand Messages
• Dan-- 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
Message 1 of 13 , May 1, 2003
Dan--
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.

-Mike

-----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.

Dan

--- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
wrote:
> John--
>
> The image on the page is from a simplified version of the
> using at the time. There's a better version of the actual
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
just track
> a simple 50% estimate of the time left to completion. The work is
> 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
specific
> 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
90%
>
> 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
those
> to be the
> > best way to capture requirements for just about any agile
project.
> This way
> > they are not too small, not too big, but typically "just right"
for
> > estimating. Stories also avoid problems with task-estimating
where
> many of
> > the tasks are highly similar, which leads to a systematic error
in
> 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
> > 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
run
> over by a
> > bus or anything like that in this estimate.
> >
> > My project schedule is then the sum of the 50% unbuffered
estimates
> 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
individual
> > 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
to
> 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
> 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
team
> > has any experience with is STARTING a product release with
Scrum.
> >
> > 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
will
> be
> > able to deliver a product with XY&Z in it on date D, without
first
> > doing enough of a design analysis on the feature list to feel
like
> 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-
project
> > estimates must be given and contracted upon. What is done in
this
> > case? Is decomposing the user stories into what we feel are
month-
> > 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
http://docs.yahoo.com/info/terms/

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
• ... From: Mike Cohn [mailto:mike@mountaingoatsoftware.com] ... Mike, Just to compare notes -- the numbers we use/like are substantially different. We typically
Message 2 of 13 , May 2, 2003
-----Original Message-----
From: Mike Cohn [mailto:mike@...]
> 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").

Mike,

Just to compare notes -- the numbers we use/like are
substantially different.

We typically don't have much restrictions on story size
i.e. entries in the Product Backlog, except that they
need to be contained within a Sprint (2+ weeks).

On the other hand, we prefer more granular tasks,
preferably 2-4 hrs, but ranging anywhere from 1/2 hr to
8 hrs. The idea with this granularity is that on
the average a Scrum team member can get on the average
4-5 tasks done per day, and feel comfortable
reporting estimates and progress at the Scrum meetings
_and_ delivering _visible_ daily chunks of functionality to
the Daily Build and/or automated test processes.

We use both story cards and task cards together
with spreadsheets and/or a variety of issue managers
to keep track of daily progress -- always measured
as time to completion and as of late, user acceptance
tests passed.

We typically have dozens if not hundreds of builds
per day but at least one build at the end of the day, the
"Daily Build", is published to stakeholders and/or
user acceptance people because we value people-to-
people, and people-to-software interactions. We
currently don't believe all user acceptance tests
can or should be automated despite the recent
interest in automated user acceptance:

http://www.fitnesse.org
http://fit.c2.com

These are very cool tools indeed but we still value
"people interactions" more over "processes and _tools".

Hm, where did I hear that before?

- Mike

-----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.

Dan

--- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
wrote:
> John--
>
> The image on the page is from a simplified version of the
> using at the time. There's a better version of the actual
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
just track
> a simple 50% estimate of the time left to completion. The work is
> 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
specific
> 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
90%
>
> 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
those
> to be the
> > best way to capture requirements for just about any agile
project.
> This way
> > they are not too small, not too big, but typically "just right"
for
> > estimating. Stories also avoid problems with task-estimating
where
> many of
> > the tasks are highly similar, which leads to a systematic error
in
> 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
> > 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
run
> over by a
> > bus or anything like that in this estimate.
> >
> > My project schedule is then the sum of the 50% unbuffered
estimates
> 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
individual
> > 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
to
> 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
> 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
team
> > has any experience with is STARTING a product release with
Scrum.
> >
> > 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
will
> be
> > able to deliver a product with XY&Z in it on date D, without
first
> > doing enough of a design analysis on the feature list to feel
like
> 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-
project
> > estimates must be given and contracted upon. What is done in
this
> > case? Is decomposing the user stories into what we feel are
month-
> > 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
http://docs.yahoo.com/info/terms/

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

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

• I was referring to the estimating we do based on the very preliminary user stories in the product backlog. At that time we don t have enough detail to break
Message 3 of 13 , May 2, 2003
I was referring to the estimating we do based on the very preliminary user
stories in the product backlog. At that time we don't have enough detail to
break things down into 2-8 hour tasks. But, you're right, things need to be
much more granular when planning the work within a given sprint. Within a
sprint my approach seems consistent with yours.

--Mike

-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Friday, May 02, 2003 3:33 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Re: Planning a product release

-----Original Message-----
From: Mike Cohn [mailto:mike@...]
> 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").

Mike,

Just to compare notes -- the numbers we use/like are
substantially different.

We typically don't have much restrictions on story size
i.e. entries in the Product Backlog, except that they
need to be contained within a Sprint (2+ weeks).

On the other hand, we prefer more granular tasks,
preferably 2-4 hrs, but ranging anywhere from 1/2 hr to
8 hrs. The idea with this granularity is that on
the average a Scrum team member can get on the average
4-5 tasks done per day, and feel comfortable
reporting estimates and progress at the Scrum meetings
_and_ delivering _visible_ daily chunks of functionality to
the Daily Build and/or automated test processes.

We use both story cards and task cards together
with spreadsheets and/or a variety of issue managers
to keep track of daily progress -- always measured
as time to completion and as of late, user acceptance
tests passed.

We typically have dozens if not hundreds of builds
per day but at least one build at the end of the day, the
"Daily Build", is published to stakeholders and/or
user acceptance people because we value people-to-
people, and people-to-software interactions. We
currently don't believe all user acceptance tests
can or should be automated despite the recent
interest in automated user acceptance:

http://www.fitnesse.org
http://fit.c2.com

These are very cool tools indeed but we still value
"people interactions" more over "processes and _tools".

Hm, where did I hear that before?

- Mike

-----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.

Dan

--- In scrumdevelopment@yahoogroups.com, "Mike Cohn" <mike@m...>
wrote:
> John--
>
> The image on the page is from a simplified version of the
> using at the time. There's a better version of the actual
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
just track
> a simple 50% estimate of the time left to completion. The work is
> 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
specific
> 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
90%
>
> 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
those
> to be the
> > best way to capture requirements for just about any agile
project.
> This way
> > they are not too small, not too big, but typically "just right"
for
> > estimating. Stories also avoid problems with task-estimating
where
> many of
> > the tasks are highly similar, which leads to a systematic error
in
> 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
> > 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
run
> over by a
> > bus or anything like that in this estimate.
> >
> > My project schedule is then the sum of the 50% unbuffered
estimates
> 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
individual
> > 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
to
> 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
> 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
team
> > has any experience with is STARTING a product release with
Scrum.
> >
> > 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
will
> be
> > able to deliver a product with XY&Z in it on date D, without
first
> > doing enough of a design analysis on the feature list to feel
like
> 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-
project
> > estimates must be given and contracted upon. What is done in
this
> > case? Is decomposing the user stories into what we feel are
month-
> > 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
http://docs.yahoo.com/info/terms/

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

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