Estimation / story points

Expand Messages
• Colleagues, I know this is a hoary topic, it s very muddled in my mind right now, so I hope you don t mind me asking for opinions. The current consensus where
Message 1 of 23 , Feb 1, 2012
Colleagues,

I know this is a hoary topic, it's very muddled in my mind right now, so I hope you don't mind me asking for opinions.

The current consensus where I am is to estimate both the product backlog and the sprint backlog in story points, in terms of complexity, on the modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200.

I understand that for a yardstick for 1 point, you could take a basic feature like a simple HTML form with no backend. So then is 8, literally 8 times more complex than this? 200, is 200 times more complex? (do you see where I'm going, 200 times as complex as a form is problematic to envisage?)

An alternative would be to do a comparative estimate of the items in a backlog, so the most complex is 200, the simplest is 1, and the others are arrayed in between. Obviously the biggest item in the product backlog would be a lot bigger than the biggest in the sprint backlog, so you'd have to preserve the product backlog scale when estimating the sprint backlog, in order to keep the estimates commensurable.

There's a big temptation for both the team and me to tie these back to ideal time in some way, so that an "8" is 1 ideal day, for instance. So do you actively avoid that, even as a yardstick when you're trying to get an initial sense of the points scale?

Thanks as always,
Michael

• ... Yes. Impossible to a first degree of approximation. ... Or something. What about time drift? ... Don t estimate. Measure. Ron Jeffries www.XProgramming.com
Message 2 of 23 , Feb 1, 2012

On Feb 1, 2012, at 6:52 AM, Michael Jones wrote:

I understand that for a yardstick for 1 point, you could take a basic feature like a simple HTML form with no backend. So then is 8, literally 8 times more complex than this? 200, is 200 times more complex? (do you see where I'm going, 200 times as complex as a form is problematic to envisage?)

Yes. Impossible to a first degree of approximation.

An alternative would be to do a comparative estimate of the items in a backlog, so the most complex is 200, the simplest is 1, and the others are arrayed in between. Obviously the biggest item in the product backlog would be a lot bigger than the biggest in the sprint backlog, so you'd have to preserve the product backlog scale when estimating the sprint backlog, in order to keep the estimates commensurable.

Or something. What about time drift?

There's a big temptation for both the team and me to tie these back to ideal time in some way, so that an "8" is 1 ideal day, for instance. So do you actively avoid that, even as a yardstick when you're trying to get an initial sense of the points scale?

Don't estimate. Measure.

Ron Jeffries
I'm really pissed off by what people are passing off as "agile" these days.
You may have a red car, but that does not make it a Ferrari.
-- Steve Hayes

• On Wed, Feb 1, 2012 at 06:52, Michael Jones ... That s the way we do it here (using the Mike Cohn cards, actually). But... ... What we *have* found is that
Message 3 of 23 , Feb 1, 2012
On Wed, Feb 1, 2012 at 06:52, Michael Jones wrote:

Colleagues,

I know this is a hoary topic, it's very muddled in my mind right now, so I hope you don't mind me asking for opinions.

That's why the list exists... <wink>

The current consensus where I am is to estimate both the product backlog and the sprint backlog in story points, in terms of complexity, on the modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200.

I understand that for a yardstick for 1 point, you could take a basic feature like a simple HTML form with no backend. So then is 8, literally 8 times more complex than this?

That's the way we do it here (using the Mike Cohn cards, actually). But...

200, is 200 times more complex? (do you see where I'm going, 200 times as complex as a form is problematic to envisage?)

...that's the reason we don't use 200s.

What we *have* found is that using the "mod Fib" scale fits our brains better than the "powers of two" scale. "The grommel looks about as complex as the frib and the werp combined, and the werp was as big a task as the fooble and the nork."

But we've also found that once you get to about one order of magnitude between the smallest normally-occuring task, the relative sizes don't fit in our heads too well.

So we use a scale that looks like this in our planning poker sessions:

0 - "Doesn't take any time at all, but I have to remember to do this." Reserved for administrivia things like a making a single phone call or double-checking that something occurred. I know some teams consider this to be backlog "pollution", but that's the way we use it.
1/2 - "Quick fix, test, build". Things like adding a chunk of prescribed verbiage to an existing feature UI.
1, 2, 3, 5 - normal task sizes
8 - "ugh, that's going to be a pain, but I don't see a way to break it down. I'm gonna need some help making sure it doesn't go off in the weeds."
13 - "I'm declaring this story too big to estimate". We've passed a *few* 13s in our history, but to be honest, our track record is pretty iffy on these, so 13 is pretty much only used as a "timebox this unknown or research spike to no more than this sprint."

We don't use the rest of the values on the cards, except occasionally for comedic effect.

An alternative would be to do a comparative estimate of the items in a backlog, so the most complex is 200, the simplest is 1, and the others are arrayed in between. Obviously the biggest item in the product backlog would be a lot bigger than the biggest in the sprint backlog, so you'd have to preserve the product backlog scale when estimating the sprint backlog, in order to keep the estimates commensurable.

We do "T-shirt sizing" (S, M, L, XL) on those items, to keep from being tempted to retroactively justify the numbers. "But this was an 8 on the product backlog, how can the stories be of size 2, 3, 3, and 5?!"

There's a big temptation for both the team and me to tie these back to ideal time in some way, so that an "8" is 1 ideal day, for instance. So do you actively avoid that, even as a yardstick when you're trying to get an initial sense of the points scale?

I can only tell you the way *we* actively avoid it: we remember that we tried it, and it failed miserably.

Over the course of a project, we do start to get a feel that, given current pressures, and current project items, and current team members, we can usually tackle about (for example, on our current project) 13 points in a sprint. But that's *measured velocity*, and not something you can get in an initial "sense", and we intentionally reset that to zero on a new project (we usually go by some variation of "weighted average of n past iterations", but that's another discussion).

--
Tim Lesher <tlesher@...>
• Hi Michael, Tim has given a great reply. I work in the same way: 13 is too big to fit into a sprint (even if the velocity is normally 30), and is an indication
Message 4 of 23 , Feb 1, 2012
Hi Michael,

Tim has given a great reply. I work in the same way: 13 is too big to fit into a sprint (even if the velocity is normally 30), and is an indication that the story needs to be split to understand it better.
If a story isn't sized such that it could be finished in max. 3 days by a couple of people, then it's too big.

I do, however, use the larger cards to estimate things that are still very far off. This is simply to get a feel of their size so 'the business' can tell whether it's going to be worth the effort to even spend time splitting them into manageble bits. T-Shirt sizing would work just as well (probably better), but people often seem to be more comfortable with the false accuracy of numbers, and I have trouble enough getting them to be OK with not using time estimates...

Wouter

On Wed, Feb 1, 2012 at 12:52 PM, Michael Jones wrote:

Colleagues,

I know this is a hoary topic, it's very muddled in my mind right now, so I hope you don't mind me asking for opinions.

The current consensus where I am is to estimate both the product backlog and the sprint backlog in story points, in terms of complexity, on the modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200.

I understand that for a yardstick for 1 point, you could take a basic feature like a simple HTML form with no backend. So then is 8, literally 8 times more complex than this? 200, is 200 times more complex? (do you see where I'm going, 200 times as complex as a form is problematic to envisage?)

An alternative would be to do a comparative estimate of the items in a backlog, so the most complex is 200, the simplest is 1, and the others are arrayed in between. Obviously the biggest item in the product backlog would be a lot bigger than the biggest in the sprint backlog, so you'd have to preserve the product backlog scale when estimating the sprint backlog, in order to keep the estimates commensurable.

There's a big temptation for both the team and me to tie these back to ideal time in some way, so that an "8" is 1 ideal day, for instance. So do you actively avoid that, even as a yardstick when you're trying to get an initial sense of the points scale?

Thanks as always,
Michael

--
Wouter Lagerweij         | wouter@...
• I have never seen a team use 200 before but if you feel you need that for really large stories then go for it. But frankly there s so much uncertainty already
Message 5 of 23 , Feb 1, 2012
I have never seen a team use 200 before but if you feel you need that for really large stories then go for it. But frankly there's so much uncertainty already in a 40 point story, anything beyond that is so inaccurate anyways it doesn't make much difference. If you just called them big and very big it would mean the same thing..

In regards your question, yes an 8 point story is about twice as big (effort, complexity etc) as a 5 point Story. A two Point story is twice as big as a 1 point story. etc.

Try to avoid the temptation of tying points to days or hours. If the team is struggling in the beginning, it's ok to start that way. But try avoid it if you can. Teams actually get the hang of triangulating stories quite quickly and get quite accurate with it in the end.

By the way, i'd rather add 0, 1/2 to the Fibonacci scale than 200

There's many ways to get started. One way is to do it the way you suggest, start with a small story give it a 1. Find the largest Story give it a 40 and then start distributing them into buckets in between. You can also start out by creating buckets small medium and large. Distribute the stories. Then take the smalls and break them down in 1, 2, and 3 pointers. Take the mediums and break them into 5, 8 and maybe 13's. Take the high's and ... either put them in the break down further bucket or go ahead and use 40, 100, 200 but it doesn't have much value at this point.

I hope this helps
Jack
www.agilebuddy.com

--- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
>
> Colleagues,
>
> I know this is a hoary topic, it's very muddled in my mind right now, so I
> hope you don't mind me asking for opinions.
>
>
> The current consensus where I am is to estimate both the product backlog
> and the sprint backlog in story points, in terms of complexity, on the
> modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200.
>
> I understand that for a yardstick for 1 point, you could take a basic
> feature like a simple HTML form with no backend. So then is 8, literally 8
> times more complex than this? 200, is 200 times more complex? (do you see
> where I'm going, 200 times as complex as a form is problematic to envisage?)
>
> An alternative would be to do a comparative estimate of the items in a
> backlog, so the most complex is 200, the simplest is 1, and the others are
> arrayed in between. Obviously the biggest item in the product backlog would
> be a lot bigger than the biggest in the sprint backlog, so you'd have to
> preserve the product backlog scale when estimating the sprint backlog, in
> order to keep the estimates commensurable.
>
> There's a big temptation for both the team and me to tie these back to
> ideal time in some way, so that an "8" is 1 ideal day, for instance. So do
> you actively avoid that, even as a yardstick when you're trying to get an
> initial sense of the points scale?
>
>
> Thanks as always,
> Michael
>
• Hi all, Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write don t estimate,
Message 6 of 23 , Feb 2, 2012
Hi all,

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Thanks again,
Michael

On Thu, Feb 2, 2012 at 3:17 AM, JackM <jack@...> wrote:

I have never seen a team use 200 before but if you feel you need that for really large stories then go for it. But frankly there's so much uncertainty already in a 40 point story, anything beyond that is so inaccurate anyways it doesn't make much difference. If you just called them big and very big it would mean the same thing..

In regards your question, yes an 8 point story is about twice as big (effort, complexity etc) as a 5 point Story. A two Point story is twice as big as a 1 point story. etc.

Try to avoid the temptation of tying points to days or hours. If the team is struggling in the beginning, it's ok to start that way. But try avoid it if you can. Teams actually get the hang of triangulating stories quite quickly and get quite accurate with it in the end.

By the way, i'd rather add 0, 1/2 to the Fibonacci scale than 200

There's many ways to get started. One way is to do it the way you suggest, start with a small story give it a 1. Find the largest Story give it a 40 and then start distributing them into buckets in between. You can also start out by creating buckets small medium and large. Distribute the stories. Then take the smalls and break them down in 1, 2, and 3 pointers. Take the mediums and break them into 5, 8 and maybe 13's. Take the high's and ... either put them in the break down further bucket or go ahead and use 40, 100, 200 but it doesn't have much value at this point.

I hope this helps
Jack
www.agilebuddy.com

--- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
>
> Colleagues,
>
> I know this is a hoary topic, it's very muddled in my mind right now, so I
> hope you don't mind me asking for opinions.
>
>
> The current consensus where I am is to estimate both the product backlog
> and the sprint backlog in story points, in terms of complexity, on the
> modified Fibonacci scale - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200.
>
> I understand that for a yardstick for 1 point, you could take a basic
> feature like a simple HTML form with no backend. So then is 8, literally 8
> times more complex than this? 200, is 200 times more complex? (do you see
> where I'm going, 200 times as complex as a form is problematic to envisage?)
>
> An alternative would be to do a comparative estimate of the items in a
> backlog, so the most complex is 200, the simplest is 1, and the others are
> arrayed in between. Obviously the biggest item in the product backlog would
> be a lot bigger than the biggest in the sprint backlog, so you'd have to
> preserve the product backlog scale when estimating the sprint backlog, in
> order to keep the estimates commensurable.
>
> There's a big temptation for both the team and me to tie these back to
> ideal time in some way, so that an "8" is 1 ideal day, for instance. So do
> you actively avoid that, even as a yardstick when you're trying to get an
> initial sense of the points scale?
>
>
> Thanks as always,
> Michael
>

• Hello, Michael, Please read the following aware that I was coach of the team that first invented story point estimates. It s even possible that I came up with
Message 7 of 23 , Feb 2, 2012
Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• Michael, ... I m not part of that everyone. I recommend the Abbreviated Fibonacci Series: 1, Too Big. The next question is usually How do you know what s
Message 8 of 23 , Feb 2, 2012
Michael,

On 2/2/12 4:56 AM, Michael Jones wrote:
> Everyone seems to converge on a consensus that the following sizes are
> useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40
> for larger ones. This isn't because higher numbers are automatically too
> big (after all 200 could be an HTML form - it's an arbitrary scale) but
> because 0-40 gives you all the relative scale options you should need to
> estimate user stories in a sprint (anything 80 times larger than a tiny
> job should be broken down further)

I'm not part of that "everyone." I recommend the Abbreviated Fibonacci
Series: 1, Too Big.

The next question is usually "How do you know what's too big?" I like
Ron's suggestion that a story should fit in a couple days' work. I also
think that smaller than that is great, and perhaps preferable. But if
you can't envision it being done in 2 days, it's definitely too big.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• ... Not everyone. I prefer a smaller, simpler range of choices and find the Fibonacci sequence distracting. The important thing isn t the estimates themselves
Message 9 of 23 , Feb 2, 2012
On Feb 2, 2012, at 4:56 AM, Michael Jones <michaelhardwinjones@...> wrote:

> Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones.

Not everyone. I prefer a smaller, simpler range of choices and find the Fibonacci sequence distracting. The important thing isn't the estimates themselves (which are guaranteed wrong), though a team estimation activity can lead to useful discussion about the actual scope of each PBI.

--mj

Sent from a phone that often corrects words I tapped to words I may not have meant.
• Michael Jones, Maybe I m getting ahead of Ron s coaching strategy here (maybe he s trying to lead you into actually telling you about story counting
Message 10 of 23 , Feb 2, 2012
Michael Jones,

Maybe I'm getting ahead of Ron's "coaching strategy" here (maybe he's trying to lead you into actually telling you about "story counting" instead of story point estimation), or maybe Ron doesn't realize that you are not familiar with his "story counting" strategy.  Anyway, in reading this thread, while Ron makes a lot of great points, it doesn't appear to me that you're fully aware of the technique that he is suggesting.

(Also, Ron and Chet, both on this list, are the foremost thought leaders in the industry on User Stories, and are co-creators of the practice(prob with others), as far as I'm concerned.  This also makes them the foremost thought leaders on Story Point estimation as well.)

Anyway, I've documented Ron's strategy, along with some minor commentary/opinion from me, here:
http://www.scrumcrazy.com/User+Story+Pattern+-+Micro+Stories

Ron,
Have you guys documented this anywhere besides emails?  An article perhaps on your web site?  A forthcoming book?  It really needs to get "out there," IMHO.  I avoided citing your name on my web site because I didn't want anyone thinking that you approved of, or endorsed, what I wrote on the page.  I'd love to see a short book on _Story Points are Dead! Don't Estimate Stories, Count Them!_

-------
http://www.ScrumCrazy.com

From: RonJeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Thursday, February 2, 2012 4:42 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• Good post Charles, and Ron, some guidance on story counting will definitely help. My guess is (and I might be wrong ) probably this is something similar to
Message 11 of 23 , Feb 2, 2012

Good post Charles, and Ron, some guidance on "story counting" will definitely help.

My guess is (and I might be wrong ) probably this is something similar to the lean practice of having equally sized/predictable chunk of work do as to ensure smooth flow. But then, I ask myself, how would you go about doing a release plan based in this approach ? Also, if the item is somewhere down in the list (pbi), would we still use the same approach, considering that the pbi is usually "DEEP" ( http://blog.mountaingoatsoftware.com/make-the-product-backlog-deep )

Unrelated to this, I have a different question on using t-short for sizing stories. How would someone use t-shirt sizes to estimate a release plan? Should we convert them to some number series ( pseudo Fibonacci /exponential ) before we can estimate a release date?

Cheers,
Ram

--
Sent from a phone that often corrects words I tapped (or "swyped" )  to words I may not have meant.

On Feb 3, 2012 2:15 AM, "Charles Bradley - Scrum Coach CSM PSM I" <chuck-lists2@...> wrote:

Michael Jones,

Maybe I'm getting ahead of Ron's "coaching strategy" here (maybe he's trying to lead you into actually telling you about "story counting" instead of story point estimation), or maybe Ron doesn't realize that you are not familiar with his "story counting" strategy.  Anyway, in reading this thread, while Ron makes a lot of great points, it doesn't appear to me that you're fully aware of the technique that he is suggesting.

(Also, Ron and Chet, both on this list, are the foremost thought leaders in the industry on User Stories, and are co-creators of the practice(prob with others), as far as I'm concerned.  This also makes them the foremost thought leaders on Story Point estimation as well.)

Anyway, I've documented Ron's strategy, along with some minor commentary/opinion from me, here:

Ron,
Have you guys documented this anywhere besides emails?  An article perhaps on your web site?  A forthcoming book?  It really needs to get "out there," IMHO.  I avoided citing your name on my web site because I didn't want anyone thinking that you approved of, or endorsed, what I wrote on the page.  I'd love to see a short book on _Story Points are Dead! Don't Estimate Stories, Count Them!_

-------
http://www.ScrumCrazy.com

From: RonJeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Thursday, February 2, 2012 4:42 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• Hi Ron, Jack, Charles, thanks for the replies, (FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should
Message 12 of 23 , Feb 3, 2012
Hi Ron, Jack, Charles, thanks for the replies,

(FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should be slicing the user stories thinly enough that they're roughly the same (or average out) and can just be counted up / measured.

To the extent that all systems of measurement place some sort of incentive on the participants, it seems this one is uniquely benign - its only incentive is to encourage developers to slice stories as thin as possible - and no developer worth their salt would slice stories unnecessarily thin, thereby creating more complication for them when developing, just to inflate their estimate.

It puts the focus back where it belongs, on the units of value-delivering functionality, rather than the measurement scale / estimation exercise, etc.

The only drawback I can see is that, in the product backlog, user stories won't yet be sliced - they're of massively varying sizes; so without any sort of number next to them, it's harder to grab a set of about the right amount of them to put forward for the sprint planning.

However this is easily done by gut feel and experience during the sprint planning, the developers drawing down and breaking down stories until they feel they've got the right amount (or until the number they have matches their velocity in terms of completed stories, not points).

Ron, you provide exceedingly useful thinking / measurement points if we do start estimating in the first instance (because of organisational constraints I might have to if I can't successfully pitch this alternative way, though your notes will give me considerable ammo to do so).

Thank you again!
Michael

On Thu, Feb 2, 2012 at 8:45 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:

Michael Jones,

Maybe I'm getting ahead of Ron's "coaching strategy" here (maybe he's trying to lead you into actually telling you about "story counting" instead of story point estimation), or maybe Ron doesn't realize that you are not familiar with his "story counting" strategy.  Anyway, in reading this thread, while Ron makes a lot of great points, it doesn't appear to me that you're fully aware of the technique that he is suggesting.

(Also, Ron and Chet, both on this list, are the foremost thought leaders in the industry on User Stories, and are co-creators of the practice(prob with others), as far as I'm concerned.  This also makes them the foremost thought leaders on Story Point estimation as well.)

Anyway, I've documented Ron's strategy, along with some minor commentary/opinion from me, here:

Ron,
Have you guys documented this anywhere besides emails?  An article perhaps on your web site?  A forthcoming book?  It really needs to get "out there," IMHO.  I avoided citing your name on my web site because I didn't want anyone thinking that you approved of, or endorsed, what I wrote on the page.  I'd love to see a short book on _Story Points are Dead! Don't Estimate Stories, Count Them!_

-------
http://www.ScrumCrazy.com

From: RonJeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Thursday, February 2, 2012 4:42 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• I ve heard of a practice, and am planning to try to transition my teams to this in the near future, of managing the product backlog in terms of Features, which
Message 13 of 23 , Feb 3, 2012
I've heard of a practice, and am planning to try to transition my teams to this in the near future, of managing the product backlog in terms of Features, which break into User Stories, which break into Tasks.

Stories, we know can either be counted or estimated in story points.

Features can be estimated by whatever mechanism you choose -- I'm planning to use t-shirt sizes for these as an explicit admission that trying to get any more fine-grained than that is simply impossible. For release planning purposes, we can assign numeric values to each of those sizes when trying to figure out how many features we can fit into a release but even then I won't necessarily guarantee to the customer anything better than an optimistic -- realistic -- pessimistic set of three projections.

Long story short, that's how I plan to handle the unsliced stories -- as features sized by t-shirt sizes.

(Call the epics if you prefer, but I don't really like the term -- it implies something that just goes on forever, sometimes without any point at all).

Bret Wortman

On Fri, Feb 3, 2012 at 9:17 AM, Michael Jones wrote:

Hi Ron, Jack, Charles, thanks for the replies,

(FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should be slicing the user stories thinly enough that they're roughly the same (or average out) and can just be counted up / measured.

To the extent that all systems of measurement place some sort of incentive on the participants, it seems this one is uniquely benign - its only incentive is to encourage developers to slice stories as thin as possible - and no developer worth their salt would slice stories unnecessarily thin, thereby creating more complication for them when developing, just to inflate their estimate.

It puts the focus back where it belongs, on the units of value-delivering functionality, rather than the measurement scale / estimation exercise, etc.

The only drawback I can see is that, in the product backlog, user stories won't yet be sliced - they're of massively varying sizes; so without any sort of number next to them, it's harder to grab a set of about the right amount of them to put forward for the sprint planning.

However this is easily done by gut feel and experience during the sprint planning, the developers drawing down and breaking down stories until they feel they've got the right amount (or until the number they have matches their velocity in terms of completed stories, not points).

Ron, you provide exceedingly useful thinking / measurement points if we do start estimating in the first instance (because of organisational constraints I might have to if I can't successfully pitch this alternative way, though your notes will give me considerable ammo to do so).

Thank you again!
Michael

On Thu, Feb 2, 2012 at 8:45 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:

Michael Jones,

Maybe I'm getting ahead of Ron's "coaching strategy" here (maybe he's trying to lead you into actually telling you about "story counting" instead of story point estimation), or maybe Ron doesn't realize that you are not familiar with his "story counting" strategy.  Anyway, in reading this thread, while Ron makes a lot of great points, it doesn't appear to me that you're fully aware of the technique that he is suggesting.

(Also, Ron and Chet, both on this list, are the foremost thought leaders in the industry on User Stories, and are co-creators of the practice(prob with others), as far as I'm concerned.  This also makes them the foremost thought leaders on Story Point estimation as well.)

Anyway, I've documented Ron's strategy, along with some minor commentary/opinion from me, here:

Ron,
Have you guys documented this anywhere besides emails?  An article perhaps on your web site?  A forthcoming book?  It really needs to get "out there," IMHO.  I avoided citing your name on my web site because I didn't want anyone thinking that you approved of, or endorsed, what I wrote on the page.  I'd love to see a short book on _Story Points are Dead! Don't Estimate Stories, Count Them!_

-------
http://www.ScrumCrazy.com

From: RonJeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Thursday, February 2, 2012 4:42 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• Michael, ... It s quite easy to slice those stories if you discuss what are the examples needed to indicate the stories work as expected. If a large number of
Message 14 of 23 , Feb 3, 2012
Michael,

On 2/3/12 9:17 AM, Michael Jones wrote:
> The only drawback I can see is that, in the product backlog, user
> stories won't yet be sliced - they're of massively varying sizes; so
> without any sort of number next to them, it's harder to grab a set of
> about the right amount of them to put forward for the sprint planning.

It's quite easy to slice those stories if you discuss what are the
examples needed to indicate the stories work as expected. If a large
number of examples are needed, then you can slice the story into smaller
bundles of those examples.

See http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• Vasco Duarte had a nice blog post on the subject of leaving out estimation: http://softwaredevelopmenttoday.blogspot.com/ Leaves me with a question, though.
Message 15 of 23 , Feb 3, 2012
Vasco Duarte had a nice blog post on the subject of leaving out estimation: http://softwaredevelopmenttoday.blogspot.com/

Leaves me with a question, though. I've been using Planning Poker for a large part as a catalyst for the Conversation part of user stories. This is not perfect (people can estimate roughly the same based on wildly different assumptions), but still remarkably effective, especially for new teams.

What are all the people that don't do estimates anymore using as mechanisms for this?

My main other is the Confirmation part: talking about the acceptance criteria/examples, as George is saying, is a great way to find out that we have understanding on what the requirement is. That doesn't seem to bring the more technical discussions up, though, that I would expect during planning poker.

Wouter

On Fri, Feb 3, 2012 at 5:09 PM, George Dinwiddie wrote:
Michael,

On 2/3/12 9:17 AM, Michael Jones wrote:
> The only drawback I can see is that, in the product backlog, user
> stories won't yet be sliced - they're of massively varying sizes; so
> without any sort of number next to them, it's harder to grab a set of
> about the right amount of them to put forward for the sprint planning.

It's quite easy to slice those stories if you discuss what are the
examples needed to indicate the stories work as expected. If a large
number of examples are needed, then you can slice the story into smaller
bundles of those examples.

See http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

- George

--
----------------------------------------------------------------------
* George Dinwiddie *                      http://blog.gdinwiddie.com
Software Development                    http://www.idiacomputing.com
Consultant and Coach                    http://www.agilemaryland.org
----------------------------------------------------------------------

------------------------------------

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

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-digest@yahoogroups.com
scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

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

--
Wouter Lagerweij         | wouter@...
• Hi ashish, ... Given about two examples, teams learn how to do this in an hour or two. Ron Jeffries www.XProgramming.com I m not bad, I m just drawn that way.
Message 16 of 23 , Feb 3, 2012
Hi ashish,

On Feb 2, 2012, at 5:13 PM, ashish_wrt wrote:

How successful people have been in practice in breaking down stories to equal chunks of 1 -3 days? How much effort has it been?

Given about two examples, teams learn how to do this in an hour or two.

Ron Jeffries
I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

• ... Yes. And even then we want to be focused on value, as you emphasize below ... ... Yes, well spotted! Often people object to story slicing for two reasons:
Message 17 of 23 , Feb 4, 2012

On Feb 3, 2012, at 9:17 AM, Michael Jones wrote:

(FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should be slicing the user stories thinly enough that they're roughly the same (or average out) and can just be counted up / measured.

Yes. And even then we want to be focused on value, as you emphasize below ...

To the extent that all systems of measurement place some sort of incentive on the participants, it seems this one is uniquely benign - its only incentive is to encourage developers to slice stories as thin as possible - and no developer worth their salt would slice stories unnecessarily thin, thereby creating more complication for them when developing, just to inflate their estimate.

Yes, well spotted! Often people object to story slicing for two reasons: first, they can't see how to get their business-side people to see value in thin slices. Frankly, this is one of those objections that doesn't hold up: when we spend even a couple of hours on story slicing, everyone gets it.

Second, they'll raise the concern about slicing too small. As you correctly observe, developers aren't quite that stupid. This is especially true if we aren't making the number of stories done into a metric. If we do make it a metric, people will game it.

It puts the focus back where it belongs, on the units of value-delivering functionality, rather than the measurement scale / estimation exercise, etc.

Well, the focus really belongs on steering: selecting which things to do, based on perceived / estimated value.

The only drawback I can see is that, in the product backlog, user stories won't yet be sliced - they're of massively varying sizes; so without any sort of number next to them, it's harder to grab a set of about the right amount of them to put forward for the sprint planning.

Not hard at all if you do as we teach and select stories in backlog grooming, which is not done by the Product Owner alone in a small room, but with a few team members. This is where stories get trimmed down from big blobs of fantasy into crisp things to do.

However this is easily done by gut feel and experience during the sprint planning, the developers drawing down and breaking down stories until they feel they've got the right amount (or until the number they have matches their velocity in terms of completed stories, not points).

After the earliest Sprints, I would try to avoid doing much splitting during planning, though there will be some. I'd rather see the PO show up with pretty good stories. In addition, we really need the acceptance criteria to be ready. This means most of this work needs to be done in grooming time, not planning time.

Ron, you provide exceedingly useful thinking / measurement points if we do start estimating in the first instance (because of organisational constraints I might have to if I can't successfully pitch this alternative way, though your notes will give me considerable ammo to do so).

I try to be helpful, if not easy ... :)

Ron Jeffries
I'm really pissed off by what people are passing off as "agile" these days.
You may have a red car, but that does not make it a Ferrari.
-- Steve Hayes

• Hi Micheal, Below is the link to a very practical book that shows Agile teams how to gather requirements to obtain the same level of granularity called Scrum
Message 18 of 23 , Feb 4, 2012
Hi Micheal,

Below is the link to a very practical book that shows Agile teams how to gather requirements to obtain the same level of granularity called Scrum in Action (Agile Project Management and Software Development).

http://www.amazon.com/Scrum-Action-1st-Ed-ebook/dp/B004NNV72A/ref=tmm_kin_title_0?ie=UTF8&m=AG56TWVU5XWC2&qid=1328365525&sr=8-1

Likewise, you will find in this book also some advice as to how to use an easy estimate framework, not based on the traditional poker discussion which may be influenced by senior technical staff but based on provable and objective criteria, which you could use as an easy reference for future team's performance.

Jessica.

From: Michael Jones <michaelhardwinjones@...>
To: scrumdevelopment@yahoogroups.com
Sent: Friday, February 3, 2012 8:17 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hi Ron, Jack, Charles, thanks for the replies,

(FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should be slicing the user stories thinly enough that they're roughly the same (or average out) and can just be counted up / measured.

To the extent that all systems of measurement place some sort of incentive on the participants, it seems this one is uniquely benign - its only incentive is to encourage developers to slice stories as thin as possible - and no developer worth their salt would slice stories unnecessarily thin, thereby creating more complication for them when developing, just to inflate their estimate.

It puts the focus back where it belongs, on the units of value-delivering functionality, rather than the measurement scale / estimation exercise, etc.

The only drawback I can see is that, in the product backlog, user stories won't yet be sliced - they're of massively varying sizes; so without any sort of number next to them, it's harder to grab a set of about the right amount of them to put forward for the sprint planning.

However this is easily done by gut feel and experience during the sprint planning, the developers drawing down and breaking down stories until they feel they've got the right amount (or until the number they have matches their velocity in terms of completed stories, not points).

Ron, you provide exceedingly useful thinking / measurement points if we do start estimating in the first instance (because of organisational constraints I might have to if I can't successfully pitch this alternative way, though your notes will give me considerable ammo to do so).

Thank you again!
Michael

On Thu, Feb 2, 2012 at 8:45 PM, Charles Bradley - Scrum Coach CSM PSM I wrote:

Michael Jones,

Maybe I'm getting ahead of Ron's "coaching strategy" here (maybe he's trying to lead you into actually telling you about "story counting" instead of story point estimation), or maybe Ron doesn't realize that you are not familiar with his "story counting" strategy.  Anyway, in reading this thread, while Ron makes a lot of great points, it doesn't appear to me that you're fully aware of the technique that he is suggesting.

(Also, Ron and Chet, both on this list, are the foremost thought leaders in the industry on User Stories, and are co-creators of the practice(prob with others), as far as I'm concerned.  This also makes them the foremost thought leaders on Story Point estimation as well.)

Anyway, I've documented Ron's strategy, along with some minor commentary/opinion from me, here:

Ron,
Have you guys documented this anywhere besides emails?  An article perhaps on your web site?  A forthcoming book?  It really needs to get "out there," IMHO.  I avoided citing your name on my web site because I didn't want anyone thinking that you approved of, or endorsed, what I wrote on the page.  I'd love to see a short book on _Story Points are Dead! Don't Estimate Stories, Count Them!_

-------
http://www.ScrumCrazy.com

From: RonJeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Thursday, February 2, 2012 4:42 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Hello, Michael,

Please read the following aware that I was coach of the team that first invented story point estimates. It's even possible that I came up with the idea myself. I hope not. :)

I'm not saying that because I'm bragging, but because I'd like you to be really wondering why one of the idea's inventors would be coming out against it.

On Feb 2, 2012, at 4:56 AM, Michael Jones wrote:

Thank you for the very thoughtful replies. Ron I appreciate you getting me to think back to first principles. One thought: you write "don't estimate, measure" - but don't you need story point estimates in advance to measure afterwards? (otherwise the only way to measure is through hours / task?)

What would have to be true for just counting the stories to work?
How hard or easy would it be to make it true?

What reasons can you think of that argue that product backlog estimation  -- at all -- is problematical?
How important are those reasons?

Everyone seems to converge on a consensus that the following sizes are useful in sprint planning: 0, 0.5, 1, 2, 3, 5, 8, 13 and perhaps 20, 40 for larger ones. This isn't because higher numbers are automatically too big (after all 200 could be an HTML form - it's an arbitrary scale) but because 0-40 gives you all the relative scale options you should need to estimate user stories in a sprint (anything 80 times larger than a tiny job should be broken down further)

Frankly, if everyone converges on this, everyone will have converged on an inferior solution. Fortunately, everyone is not going to converge on this, because many of us have moved beyond this kind of estimation, and beyond anything that seems much like estimation, and we aren't planning on going back.

Tim, it's v useful to hear how you put this into practice, and Jack I think you've given an effective blueprint for how we can get this to work for our first sprint planning, so I'm very grateful.

Yes ... if you choose to approach things this way, you've had some good advice here. Here are some things you might want to track and try to "measure" as you go forward with this kind of estimation:

• For large-scale Fibonacci to work, a 13 needs to be average to be 13 times as costly as a 1. Same for a 20 or a 40. How's that working for your team? Are your estimates remotely accurate at large scale?
• Is there any significant difference in the accuracy of the estimates? Are larger stories just as likely to get done as smaller ones? More likely? Less?
• Is there any significant difference in the stories' acceptance? Are big ones more likely to be accepted? Less?
• Is there any difference in the time it takes to get understanding of the story after it is scheduled? Any difference in the number of mistakes in understanding?
• Does there seem to be any significant difference in how "lean and mean" big stories are compared to smaller? Are there more frills in larger ones?
• Does the team's understanding of what it can really do improve through the use of these numbers, or does a planning meeting begin to seem like an exercise in numerology?
• Do you encounter arguments between programmers and managers, or programmers and product owners, saying what the estimate "should" be?
• Do you have deep and significant discussions about why the team didn't "meet its estimate", or, worse, "meet its commitment"?
•
• Do you find that your Product Owner focuses more on predicting when you'll be done, and being concerned about it, than on picking the right things to make sure you have the nearest thing to a shippable product at every moment?

And to the extent that those things happen, and to the extent that you don't like them, what will you need to change to improve things?

Now, go on and estimate. See what happens. It'll probably be better than it was before. Then try to make it better still.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

• See suggestions inline below... ________________________________ From: George Dinwiddie To: scrumdevelopment@yahoogroups.com Sent:
Message 19 of 23 , Feb 4, 2012
See suggestions inline below...

From: George Dinwiddie <lists@...>
To: scrumdevelopment@yahoogroups.com
Sent: Friday, February 3, 2012 10:09 AM
Subject: Re: [scrumdevelopment] Re: Estimation / story points

Michael,

On 2/3/12 9:17 AM, Michael Jones wrote:
> The only drawback I can see is that, in the product backlog, user
> stories won't yet be sliced - they're of massively varying sizes; so
> without any sort of number next to them, it's harder to grab a set of
> about the right amount of them to put forward for the sprint planning.

It's quite easy to slice those stories if you discuss what are the
examples needed to indicate the stories work as expected. If a large
number of examples are needed, then you can slice the story into smaller
bundles of those examples.

See http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

See also chapter 4 (visual Agile requirements), chapter 5 (objective criteria-based Agile point estimation) and chapters 6 and 7 on architecture vision and Agile release/Sprint planning in the Scrum in Action book below:

http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=sr_1_1?ie=UTF8&qid=1326093770&sr=8-1

http://www.amazon.com/Scrum-Action-1st-Ed-ebook/dp/B004NNV72A/ref=tmm_kin_title_0?ie=UTF8&m=AG56TWVU5XWC2&qid=1328365525&sr=8-1

- Jessie

- George

--
----------------------------------------------------------------------
* George Dinwiddie *                      http://blog.gdinwiddie.com
Software Development                    http://www.idiacomputing.com
Consultant and Coach                    http://www.agilemaryland.org
----------------------------------------------------------------------

------------------------------------

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

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
scrumdevelopment-digest@yahoogroups.com
scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

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

• Ron, you ve massively helped me get things straight in my head, plus given me a coherent understanding of why measuring stories makes more sense than
Message 20 of 23 , Feb 6, 2012
Ron, you've massively helped me get things straight in my head, plus given me a coherent understanding of why measuring stories makes more sense than estimating. So I thank you! If we start off with estimating (due to some organisational inertia), I'll use your guidelines to see if it's working, and I'll aim to move us to the point where we work with thinly sliced stories.

I don't want to take up more of anyone's time, but how does this work with tasks? Should teams still add tasks for each small user story, and estimate them in hours / can they do this if it helps them, as needed during the sprint and it's almost none of the Scrum Master's business (he/she's just measuring stories) / should they no longer need tasks?

I might be overthinking things, but just want to have a coherent understanding to help me present a programme to the team.

Charles, you state the following: (http://www.scrumcrazy.com/User+Story+Pattern+-+Micro+Stories)
Stories this small will require fewer (Sprint Backlog)tasks, which means less effort will be expended in creating and estimating the tasks.Some teams forgo (Sprint Backlog item)task creation and/or estimation altogether in this situation. Technically this is a violation of the Scrum Guide, but a fairly suitable substitute practice can be achieved by doing a story count burndown to reflect estimated work remaining in the Sprint (Sprint Burndown) and support team optimizations. I recommend that only *very* advanced teams ever forgo task creation and/or estimation, but if a team can execute this User Story pattern well, they are probably advanced enough to forgo the tasks.

On Sat, Feb 4, 2012 at 1:10 PM, RonJeffries wrote:

On Feb 3, 2012, at 9:17 AM, Michael Jones wrote:

(FWIW in this esteemed company) I like the idea of not estimating story points, and that the developers should be slicing the user stories thinly enough that they're roughly the same (or average out) and can just be counted up / measured.

Yes. And even then we want to be focused on value, as you emphasize below ...

To the extent that all systems of measurement place some sort of incentive on the participants, it seems this one is uniquely benign - its only incentive is to encourage developers to slice stories as thin as possible - and no developer worth their salt would slice stories unnecessarily thin, thereby creating more complication for them when developing, just to inflate their estimate.

Yes, well spotted! Often people object to story slicing for two reasons: first, they can't see how to get their business-side people to see value in thin slices. Frankly, this is one of those objections that doesn't hold up: when we spend even a couple of hours on story slicing, everyone gets it.

Second, they'll raise the concern about slicing too small. As you correctly observe, developers aren't quite that stupid. This is especially true if we aren't making the number of stories done into a metric. If we do make it a metric, people will game it.

It puts the focus back where it belongs, on the units of value-delivering functionality, rather than the measurement scale / estimation exercise, etc.

Well, the focus really belongs on steering: selecting which things to do, based on perceived / estimated value.

The only drawback I can see is that, in the product backlog, user stories won't yet be sliced - they're of massively varying sizes; so without any sort of number next to them, it's harder to grab a set of about the right amount of them to put forward for the sprint planning.

Not hard at all if you do as we teach and select stories in backlog grooming, which is not done by the Product Owner alone in a small room, but with a few team members. This is where stories get trimmed down from big blobs of fantasy into crisp things to do.

However this is easily done by gut feel and experience during the sprint planning, the developers drawing down and breaking down stories until they feel they've got the right amount (or until the number they have matches their velocity in terms of completed stories, not points).

After the earliest Sprints, I would try to avoid doing much splitting during planning, though there will be some. I'd rather see the PO show up with pretty good stories. In addition, we really need the acceptance criteria to be ready. This means most of this work needs to be done in grooming time, not planning time.

Ron, you provide exceedingly useful thinking / measurement points if we do start estimating in the first instance (because of organisational constraints I might have to if I can't successfully pitch this alternative way, though your notes will give me considerable ammo to do so).

I try to be helpful, if not easy ... :)

Ron Jeffries
I'm really pissed off by what people are passing off as "agile" these days.
You may have a red car, but that does not make it a Ferrari.
-- Steve Hayes

• Hi Michael, ... Listing tasks can be used in (at least) two ways: To make sure we ve thought about everything that has to be done; To divide up the work among
Message 21 of 23 , Feb 6, 2012
Hi Michael,

On Feb 6, 2012, at 5:29 AM, Michael Jones wrote:

I don't want to take up more of anyone's time, but how does this work with tasks? Should teams still add tasks for each small user story, and estimate them in hours / can they do this if it helps them, as needed during the sprint and it's almost none of the Scrum Master's business (he/she's just measuring stories) / should they no longer need tasks?

Listing tasks can be used in (at least) two ways:
1. To make sure we've thought about everything that has to be done;
2. To divide up the work among specialists.

The first way is good. The second is evidence that, while the team as a whole may be "cross-functional", the individuals with in it may be overly specialized. This makes it almost certain that there will be an individual who is the bottleneck in every Sprint, reducing the team's ability to go as fast as they might if people were a bit more generally capable.

I recommend thinking about tasks, for reason #1. I no longer recommend scheduling tasks, for reason #2.

Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl

• Hi Ron, So, potentially coming up with tasks as necessary / helpful for the team during the sprint planning, but not estimating, scheduling and even measuring
Message 22 of 23 , Feb 6, 2012
Hi Ron,

So, potentially coming up with tasks as necessary / helpful for the team during the sprint planning, but not estimating, scheduling and even measuring (e.g. via a burndown) them?

Burndown if done at all (I appreciate that's a separate con(tro)versation - is done on the basis of number of stories remaining.

Thanks!
Michael

On Mon, Feb 6, 2012 at 10:47 AM, RonJeffries wrote:

Hi Michael,

On Feb 6, 2012, at 5:29 AM, Michael Jones wrote:

I don't want to take up more of anyone's time, but how does this work with tasks? Should teams still add tasks for each small user story, and estimate them in hours / can they do this if it helps them, as needed during the sprint and it's almost none of the Scrum Master's business (he/she's just measuring stories) / should they no longer need tasks?

Listing tasks can be used in (at least) two ways:
1. To make sure we've thought about everything that has to be done;
2. To divide up the work among specialists.

The first way is good. The second is evidence that, while the team as a whole may be "cross-functional", the individuals with in it may be overly specialized. This makes it almost certain that there will be an individual who is the bottleneck in every Sprint, reducing the team's ability to go as fast as they might if people were a bit more generally capable.

I recommend thinking about tasks, for reason #1. I no longer recommend scheduling tasks, for reason #2.

Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl

• Thank you Ron. I will give this approach a try. I remember, a year or so back, need to have stories of same size was discussed as a major shortcoming of Kanban
Message 23 of 23 , Feb 6, 2012
Thank you Ron. I will give this approach a try.

I remember, a year or so back, need to have stories of same size was discussed as a major shortcoming of Kanban method and now it is becoming a Scrum best practice.

Ashish
http://www.agilewrap.com

--- In scrumdevelopment@yahoogroups.com, RonJeffries <ronjeffries@...> wrote:
>
> Hi ashish,
>
> On Feb 2, 2012, at 5:13 PM, ashish_wrt wrote:
>
> > How successful people have been in practice in breaking down stories to equal chunks of 1 -3 days? How much effort has it been?
>
>
> Given about two examples, teams learn how to do this in an hour or two.
>
> Ron Jeffries
> www.XProgramming.com
> I'm not bad, I'm just drawn that way. -- Jessica Rabbit
>
Your message has been successfully submitted and would be delivered to recipients shortly.