Article: User Story Estimation Techniques

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.

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.

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.

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)

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

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.

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.

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.

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.

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.

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"!

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.

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.

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

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.

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.

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.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.