Article: User Story Estimation Techniques

by Floyd Marinescu on Jul 07, 2008 |

One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article, published on InfoQ last week, gives the details about user story estimation techniques that Jay Fields, has found effective.

Read User Story Estimation Techniques, by Jay Fields. In the article, Jay covers:

Powers of two
Use four values
No averages or numbers not on the scale
Vote independently
Take the largest estimate
Large estimate gaps
Required involvement
Pigs and Chickens
Estimation group size
No laptops
Required participation
Stale estimations
Bribes

Jay Fields is a software developer and consultant at ThoughtWorks. His most recent work has been in the Domain Specific Language space where he has delivered applications that empowered domain experts to author domain logic. Jay is on InfoQ elsewhere in an interview on DSLs, a presentation on natural language development in Ruby, s well as an article on article on software development lessons from poker.

Related Editorial

Agile workshops and training

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Good job by Al Tenhundfeld Posted

Spot On by dale moody Posted

RE: vote independently by Arnon Rotem-Gal-Oz Posted

Thanks for sharing, thought i would share our story estimation technique by keith gardner Posted

Re: Thanks for sharing, thought i would share our story estimation techniqu by Rick Leandri Posted

Voting on estimation by George White Posted

Different values and gaps management by Andrea Maietta Posted

Re: Different values and gaps management by Dave Rooney Posted

Re: Different values and gaps management by Jay Fields Posted

Re: Different values and gaps management by Dave Rooney Posted

Re: Different values and gaps management by Vladimir POPOV Posted

Delphi Technique by Maurice Hagar Posted

Fibonacci & Faites vos jeux by Martien van Steenbergen Posted

Re: Fibonacci & Faites vos jeux by Jay Fields Posted

How do short estimation meetings relate to the Sprint Planning meeting? by Fred Scefi Posted

Is there nothing about design? by Wang Hongtao Posted

Should entire team be involved in Effort estimation? by Rupesh Dubey Posted

Good job by Al Tenhundfeld

Jay, thanks for the article. It's clear, pragmatic, experience-based, and most important, full of great tips for teams new to the user story world.

They're all good suggestions, but if you're trying to introduce this practice to a new team and are feeling overwhelmed by the list of things to remember, I recommend the first two and last suggestions: use 4 powers of 2 for estimates and bribe the team with treats.

Spot On by dale moody

A section I would add - Limit the length of sessions. The quality of my estimates start to degrade around the 30 min mark. For me anything over an hour and I can't remember my name never mind the title of the story I'm supposed to be estimating.

Estimation fatigue results in people switching off. To hide this fact devs tend towards the middle estimate as it reduces the chance they will be forced into a conversation about the story.

If you see anyone wilting call a halt - they probably aren't the only person struggling. I find a short break only results in a short boost, best to come back tomorrow when everyone is fresh.

On the other hand - if estimation is taking too long perhaps you're estimating too far ahead or your domain expert/BA/PM hasn't properly prepared.

RE: vote independently by Arnon Rotem-Gal-Oz

What we do is use our cellphones. Everyone keys in their estimates and then we compare notes :)

Arnon

Thanks for sharing, thought i would share our story estimation technique by keith gardner

I have recently changed jobs and came from position that had a co-located team to my new position where we are a distributed team. Also I am moving my new group from waterfall to scrum (it is a good fit due to changing priorities, seems like about every 2 -3 weeks. Changing priorities seem to be the norm in the organizations that I have worked for.).

I have done the poker planning at our estimation sessions with cards with some success, in my previous company, although we seemed to face the following challenges:

• Getting everyone to show their cards at the same time (showing cards, all at once, is a lot more challenging then one would think).
• Seeing all the cards to determine high/low.
• Making sure that everyone is focusing on the story at hand.
• When someone was remote (seems like there are always someone), trying to get them to be able to participate (let them say their number after everyone in the room is ready with card in hand, then show everyone else’s in the room. Making sure that they had all the details for the story and could hear the conversations, and follow where the team was)

I recently found a free poker planning tool that I really like:

• www.planningpoker.com/ (From Mountain Goat Software)

We also use Rally to manage our user stories:

• www.rallydev.com/

Our estimating sessions go like the following:

• In prep: A day or two before the planning session the product owner and scrum master get the user stories cleaned up (adding conditions of satisfaction, making sure there is enough detail, and prioritizing).
• In prep: A few hours before the planning session, scrum master exports the user stories from rally into the planning poker tool. I arrange by priority, because we time box our meeting to an hour and make it though as many stories as we can. We then have follow up meetings (if needed) to get through more. If we got through the higher priority ones (and any other expected to be picked up by the team) we can then go into a planning session and prioritize before next sprint.
• We use a conference call (meet me) and all have the planning poker session up and rally (we have also used web ex to allow everyone to see the same information but seems better to have everyone drive what they need to see to be effective).
• The tool facilitates and enforces showing of cards for everyone. This works great, removes a lot of the problems. (additionally the admin (scrum master), can enter in the final estimate)
• The tool also shows only the story at hand, along with the cards.
• As we flush out the user stories, questions and clarification for stories are brought someone on the team updates rally. An effective scrum master will make sure that everyone has a chance to add some clarity and keep people on there toes as discussion is facilitated.
• We do a few hands of cards until we are close to agreement, with discussion for outliers (usually high and low, but not always).
• The tool keeps track of all the estimations for the whole session.
• After: Then we plug the numbers back into rally.

I really like the way this works, and in my opinion is better then using cards in person.

Voting on estimation by George White

A tool that I've found helpful is planningpoker.com. It allows multiple team members to vote on a story. The estimations it produces are more fine-grained then the four point system advocated here (I do prefer Jay's suggest, since it keeps the focus on general levels of effort). Still this is an interesting tool for team estimation and voting.

Different values and gaps management by Andrea Maietta

Great article, I'd only like to share our slightly different technique.

We choose Fibonacci numbers for our estimates, as suggested by Mike Cohn, and we find them very useful. We also have 0 and 20 cards, but we seldom go 13 (that leaves us on a five values scale) and we practically never use them.

About the tool: we went agile, took a colored paper sheet and cut it in regular pieces, upon which we scribbled our numbers. There you go planning poker! Outdated visiting tickets can be effective too, and they also have the advantage that they spare you the cutting.

I think cutting the estimating of a story picking the greatest value can be really time effective, but for small teams I still think that a (brief) discussion about the chosen values (and the hidden risks) would improve the global understanding of the project.

Re: Different values and gaps management by Dave Rooney

I think cutting the estimating of a story picking the greatest value can be really time effective, but for small teams I still think that a (brief) discussion about the chosen values (and the hidden risks) would improve the global understanding of the project.

When using Planning Poker with larger groups, I've observed that you have a couple of low estimates, a couple of high ones, and then a cluster of estimates somewhere in the middle. I generally ask the high & low estimate providers to explain their reasoning in case there is something that the other people didn't take into account. Most often, though, the estimate used isn't necessarily the highest but rather the one from the cluster.

Dave Rooney

Mayford Technologies

Re: Different values and gaps management by Vladimir POPOV

Great article, thank you Jay.
I'd like to share an observation regarding power of 2 versus Fibonacci numbers. We have used power of 2 for our estimates, but found it to be a bit to "flat" at the project level. So we changed to the power of e. Interesting thing is that odd positions in Fibonacci sequence are very close to power of e. I.e. 1, 3, 8, 21, 55... In real life complexity level 1 to 5 is used. The last grade is used to filter stories which need to be re-estimated.

Re: Different values and gaps management by Jay Fields

Hi Dave,
Consistency is the most important thing. If you always take the middle of the road, that's almost as good, imo. Discussing it further might be helpful, but here's 2 things to think about. For one, you might get more information, but is it really valuable at that point? I've found that usually any discussion leads to going middle of road anyway, and the extra discussion usually brings out more info, but not info that the entire team actually needs. Not everyone needs every detail. Two, you don't want to discourage large estimates. Sometimes people just get a feeling that something is bigger, and that feeling is usually correct. If you force them to explain, they might give lower estimates, despite their feelings. Of course, if someone always over estimates, that's not a big deal, because we are back to consistency.

I think you're good either way truthfully, but I find taking the largest estimate to be the most efficient and participant friendly.

Cheers, Jay

Re: Different values and gaps management by Dave Rooney

Hi Jay!

Consistency is the most important thing.

Absolutely - I couldn't agree more. As I said, when I encounter an estimate that's larger than those in the "cluster", I ask how the person arrived at the estimate. If the answer confirms that there is more to the story than people thought, then of course we go with the higher estimate.

However, I sometimes receive answers like, "I don't have experience with the technology" or "I don't really understand the requirement". For the former, it makes sense to go with a lower estimate. If the person who gave the high estimate works on that story, they can pair with someone who does know the technology. For the latter, it's strictly a case where the person didn't ask enough questions in order to gain the understanding required to provide an estimate.

So, in both of these cases, I would recommend going with a lower estimate from the "cluster", but I agree that generally the "highest estimate wins"!

Dave Rooney

Mayford Technologies

Delphi Technique by Maurice Hagar

I'm surprised the Delphi technique didn't get a mention for resolving estimate variation. You wouldn't want to use it on every story but it's a nice tool to have in your pocket.

Fibonacci & Faites vos jeux by Martien van Steenbergen

Wonderful article. Thanks Jay.

While reading it, the wish to use Fibonacci numbers (a favourite I use a lot) came up. To my delight some others suggest this as well and Planning Poker uses Fib as well. Great! I'll stick to that than.

Regarding prioritizing stories by business: I use "faites vos jeux". Another poker-inspired practice.

Each business stakeholder (those who make decisions and have budget power and/or users) is given ten or twenty poker chips (fiches), say. All chips have the same value. Next, they distibute their chips over the available stories for the next two sprint as they see fit:

Does it feel good (in my heart)?

Does it make sense (rationally)?

Does it work (can it be implemented)?

Et voilà, all stories for the next two sprint are prioritized based on their VALUE.

Have the stories picked up by developers until you meet your team's velocity.

Re: Fibonacci & Faites vos jeux by Jay Fields

Fred George, one of my favorite people to work with, prefers T-Shirt sizes. The nice thing about T-Shirt sizes is they can't be averaged. I have to give him that. But, the thing I've always disliked about T-Shirt sizes is you don't throw* M, you throw a 2. I prefer to throw 1, 2, 4, or 8 fingers. There's something about having to use 2 hands that makes people really think about an 8. That extra thought usually generates some new approaches to the story -- both technically and from a business perspective. I'm not opposed to the Fibonacci approach, but it does remove my ability to throw anything above a 10. You can use 1-5 (like Vladimir POPOV mentioned in a previous comment), but then I think you are back to thinking in terms of 1-5, and putting a different number on paper. It's not terrible, but I prefer thinking, throwing and tracking on the same scale. It's more natural, and I've had great results with it.

The fact that you are already using fibonacci tells me that you are on the right track, but you might want to try powers of 2 sometime. Or if you perfer to stick with fibonacci, do so exclusively -- if you use your cell phone (like Arnon Rotem-Gal-Oz recommended), you can throw any number you want.

* by throw I mean, show -- in rock, paper, scissors style.

Thanks for the comments, Jay

How do short estimation meetings relate to the Sprint Planning meeting? by Fred Scefi

We are about to start our second project using Scrum. On the first project, we held full-day planning meetings with the developers (5 developers) and the business owners ( 6 of them) but the discussions were at such high level, that the developers did not find it very useful. We then had to call that a business solution design meeting and arrange a real Sprint Planning meeting to do the estimates but doing the User Stories from scratch in the meeting seems to be too time consuming. If the User Stories are prepared in advance, who should be creating these? Is it the BA & the business owner? When does the developer first get exposure to the user story cards?
Too many questions I know, but I really want to make Scrum work better for us.
Regards
Fred

Re: Thanks for sharing, thought i would share our story estimation techniqu by Rick Leandri

Hi Keith -

How do you load the stories into the Planning Poker tool? We use Version One. I tried using the copy/paste method directly into the tool from Excel, but the data is jumbled. Is there some sort of template to map the data into the tool? I can't find any help on the Mountain Goat site.

Thanks,
Rick

Is there nothing about design? by Wang Hongtao

When you estimate how many story points for every story,is there nothing about design?What I mean is not about the detail thing(code framework,what functions...),at least about how many modules will be involved,how many work for each modues? BTW,the background is big complext embeded sysytem.

Should entire team be involved in Effort estimation? by Rupesh Dubey

In the post you have mentioned in case of bigger teams estimation can be done by a smaller group rather than entire team getting involved, at the same time article says that everyone who is involved with these stories should be involved in estimation.Moreover as we rotate our pairs regularly isn't it important to have everyone's involvement? Or is it limited at estimation during inception as team can again re-estimate the effort during IPM meetings.

Regards
Rupesh
Thoughtworks,India