Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles User Story Estimation Techniques

User Story Estimation Techniques

This item in japanese


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 gives the details about user story estimation techniques that I've found effective.

Powers of two

Originally I estimated stories as one, two, three, four or as small, medium, large, extra-large. It was always meant to be understood that a medium was twice the size of a small and a large was twice the size of a medium (and so on), but that never seemed to translate well when it came to planning. Then someone recommended to me that I try powers of two. Suddenly we were speaking a language that the business could understand. They knew that an 8 was significantly bigger than a 1. I believe the sizes one, two, four, eight are also much more appropriate. As stories get larger they almost always contain more unknown and risk. A powers of two scale emphasizes the risk associated with large stories.

Use four values

I was once on a project that started with 1, 2, 4, 8 as their estimation values. After the first two estimation sessions less than 5% of the stories were ones and about 30% of the stories were twos. The project manager decided to get rid of the one value because it made his life easier. An interesting thing happened at each subsequent estimation meeting, suddenly only 5% of the stories were twos and many more stories had become fours. I don't think that the developers consciously changed their scale, but developers are conditioned to be skeptical. Few developers are willing to say with certainty that any given story will be as easy as the scale allows. After witnessing this type of behavior on a few different projects, I prefer a minimum of four point values. I also prefer a maximum of 4 point values. After all, it's nothing more than an estimate. If you try to give too much precision to an estimate you'll end up having to account for why you missed the mark. The idea is to get a rough idea, not a rigid plan to live off of.

No averages or numbers not on the scale

Four values allow you to get a rough estimate without spending unnecessary time focusing on precision. Sometimes a story feels larger than a two but smaller than a four. The story should not be estimated as a three. There's really no reason to use a three. The story carries enough risk or unknowns that it is not a two; therefore, it's very likely that it will actually be a four. Using an average or an off scale number can briefly (and unnecessarily) confuse a team member or stakeholder. Also, in the big picture of the project, the occasional uncommon estimate isn't likely to make much of a difference. Keep it simple, stick to the scale.

Vote independently

It's human nature to be influenced by other people. If a technical leader says a story is a two, it's likely that the rest of the team will follow his lead. For this reason I prefer an estimation process that lets each team member vote independently. This can be done by using sheets of paper that no one reveals until everyone is ready. Another option (that I prefer) is to give your estimation rock-paper-scissors (RPS) style. In our estimation meetings we talk about a story until we are ready to estimate then we all "throw" our estimations the same as you would "throw" rock, paper, or scissors. What I mean by "throw our estimation" is that if we think it's a 1 we point 1 finger. Likewise a 2 is two fingers and 4 is four fingers. If you need to throw an 8, you can use both hands.

Take the largest estimate

Even when reminded, developers seem to have a hard time estimating with a team in mind. If a developer thinks they can do the story in 1 day, they throw 1 finger. Unfortunately, that developer may not be available to do the story, and then some other team member is stuck working on a story that they thought was a 2 or even a 4. I prefer to always take the largest estimate thrown by any team member. You may consider this to be sandbagging, but in reality it's likely that each team member has identified different risks and the team member with the largest estimate has probably correctly identified that there is more risk than the other members have thought of.

Taking the largest estimate has additional benefits. If you must agree on a lower estimate then the team member with the larger estimate will need to discuss why they chose a larger value. This discussion can be uncomfortable for developers who are less senior on the team. They may not know how to do something as quickly, based on limited experience with the language or tools. Their concerns are often justified by their skill level, and it would be unfortunate if they felt uncomfortable giving their true estimate because they were afraid to discuss why it was higher.

Any discussion around taking a higher or lower value may lead to the entire team raising their value, or it may lead to that developer uncomfortably lowering their estimate. Either way, you'll need to spend more time talking and you wont have gained--in the end it's consistency that matters. You always know how many stories you expect to get done in an iteration by tracking velocity*. Therefore, even if your estimates are "bloated" so will your velocity be, thus it has no effect on planning.

Finally, taking the largest estimate can help save time in an estimation meeting. If any member of the team believes the story is an 8 he can speak up at any time while discussing the story and announce that he is going to throw an eight. Unless someone else believes that there is a large estimation gap among team members, there's no reason to continue talking about the story since it will ultimately become an eight anyway.

Large estimate gaps

When estimating it's usually the exception that the entire team agrees on the size of a story. Like I previously said, I like to handle the mismatch by always taking the larger estimate. However, sometimes a large gap represents a misunderstanding. For this reason any time there is a two value gap in estimation, additional conversation always occurs (e.g. if a team member throws a 1 and another throws a 4, some clarification needs to occur). Discussing large gaps also ensures that taking the largest estimate has less chance of being abused.

Insufficient information

On occasion a story may need leave the meeting unestimated. It's better to ask for more information than to give an estimate that you are uncomfortable with. An estimate of 8 implies that it's a large story, but you expect it to take twice as long as a 4. Therefore, don't simply estimate ill-defined stories as eights, because you will likely be expected to get it done in the same amount of time as it takes to get two stories estimated as fours completed. The goal of an estimation meeting isn't to estimate all the stories, it's to provide estimates on the stories that provide sufficient information.

Required involvement

No one enjoys estimation meetings (okay, no one I know). In my past projects the fastest reader would read the story aloud, the developers would ask the domain experts questions, and then they would estimate. When the developers weren't asking the domain experts questions, the domain experts usually did other things on their laptops. At first glance I thought this was a good use of their time, but things got missed. Later I joined a project where the manager insisted that we go around the room and make everyone read a story when it was their turn. Suddenly the domain experts were engaged because they were worried about looking silly when it was their turn to read. The meetings became much more valuable due to everyone's involvement.

Pigs and Chickens

In a ham-and-eggs restaurant, the pig is committed but the chicken is simply involved.

I often hear that the business shouldn't influence developer estimates because developers are pigs and the business is full of chickens. I actually think this is a bad analogy. It's more likely that a bad product will get the business team fired than the technology team. I'm sure the business feels just as committed as the developers. However, it is a conflict of interest to let the business interfere with estimates.

It's as simple as this, the business wants to know what functionality they can get in the next iteration. To know what to expect they need estimates. Since the business will not be writing the code, they cannot contribute proper estimates. The more they are involved (in the actual estimation), the less likely it is that they will receive realistic estimates. The best domain experts answer questions in meetings, but never assert in any way the level of effort it will take to complete any given story.

Estimation group size

Teams come in many different sizes. On smaller teams (6 or less) I suggest the entire team attend the estimation session. The many points of view are likely to solidify vision and positively contribute to an estimate. However, I believe there is a point of diminishing returns. Not everyone on a large team needs to be part of estimating each story. Additionally, it's an estimate, 6 people should be just as accurate as 15 people would be. If your team is larger than 6 people I suggest breaking into smaller groups for estimation. In general I like to get at least 3 people to estimate any given story, but no more than 6.

New stories

New stories come in two forms: new feature requests and stories that split. I generally wait to estimate new stories based on their priority. If a story needs to be done in the next iteration, it generally requires an immediate estimate. However, if the new stories aren't going to be played for several iterations it can make sense to hold off until you have enough stories to justify an estimation meeting. I find estimates from estimation meetings to be more reliable, since they come from an environment where everyone is focused solely on estimation. Stories resulting from a split provide an additional complication: they likely already have an estimate. I strongly suggest that the new stories be estimated without taking into consideration the previous estimate. If a story carried enough risk or uncertainty that it required splitting, it's not likely that the estimate is realistic--ignore the original estimate.

No laptops

At least no laptops for developers. Print the story list for everyone, or project the list on the screen, but don't ask the developers to read the story list from their laptops. Laptops almost always find ways to distract developers, thus taking away from the goal of the meeting: Getting valuable estimates.

Required participation

This suggestion is a very important one. In theory, no developer from outside the team should be attending an estimation session. That means that every developer that attends an estimation session will potentially be tasked with working on a story that's being estimated. If a developer is not comfortable estimating a story, then I'm not comfortable with them working on the story. Of course, there are exceptions. I generally give new team members one week to come up to speed before I ask that they participate in an estimation session. But, in general, a developer who refuses to participate in estimation should signal that there's a bigger issue that needs to be resolved.

Stale estimations

Teams change, projects change, and random events occur. Whatever the reason, estimations can get stale. Stale estimations don't help anyone. The development team feels pressure to deliver to stale estimates and the business expects stories to be completed according to projected velocity. It doesn't matter why estimates get stale, what matters is that the estimates are no longer realistic and the plan is no longer reliable. I've never been part of a project where the estimates didn't go stale within 12-24 weeks. It's better to admit that an estimation is stale than it is to plan with inaccurate information. For this reason, I suggest revisiting any estimation that was given more than 12 weeks ago. The estimation will hopefully still be good, but giving the developers an opportunity to speak up given new information is nothing but helpful to the business.


This is the easiest suggestion of all: Bring high quality snacks to all estimation meetings. Sugar has been scientifically linked to happiness, and happiness leads to collaboration. It's the simplest and cheapest possible way to make an estimation meeting something to look forward to. Keep in mind though, high quality is the key. If you bring the same snacks that are already sitting in the team room, it's not very exciting. On my last project I went to the bakery and got fresh baked assorted cookies every time I remembered there was a meeting.


I'd like to give special thanks to Brent Cryder, Dennis Byrne, Fred George, Joe Zenevitch, Mike Ward, and Sean Doran for helping me solidify and evolve these ideas. Just like every other list of people, mine surely leaves out other contributors, please forgive me for leaving you off.

About the author

Jay Fields is a software developer and consultant at ThoughtWorks. He has a passion for discovering and maturing innovative solutions. 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. He is also very interested in maturing software design through developer testing and software testing in general.

*Velocity: The number of points you've completed over the life of the project divided by the number of iterations. E.g. If you've completed 20 points over 5 iterations, your velocity is 4. With a velocity of 4 you can expect to get as many stories done in an iteration where their estimates total 4 (e.g. 1 story estimated as a 4, 2 stories estimated as twos, 4 stories estimated as ones, etc)

Rate this Article


Hello stranger!

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

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Good job

    by Al Tenhundfeld,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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


  • Thanks for sharing, thought i would share our story estimation technique

    by keith gardner,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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: (From Mountain Goat Software)

    We also use Rally to manage our user stories:

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A tool that I've found helpful is 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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Thanks for sharing, thought i would share our story estimation techniqu

    by Rick Leandri,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.


  • Is there nothing about design?

    by Wang Hongtao,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.


Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p