The Scrum methodology of agile software development marks a dramatic departure from waterfall management. In fact, Scrum and other agile processes were inspired by its shortcomings. The Scrum methodology emphasizes communication and collaboration, functioning software, and the flexibility to adapt to emerging business realities — all attributes that suffer in the rigidly ordered waterfall paradigm.

21st
NOV

Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

In waterfall, managers determine a team member’s workload capacity in terms of time. That is, managers estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. This is problematic because it does not distinguish between a story that is very hard to complete and one that is undemanding; it only considers how long the work will take. To put it another way, coding a feature and organizing the heaps of documentation on your desk are activities that likely take the same amount of time, but there’s no question that the former would require much more sustained concentration and effort. Because of that fact, they should be recognized as incredibly different tasks, requiring different levels of effort.

Scrum takes a considerably different approach to determining a team member’s capacity. First of all, Scrum assigns work to an entire team, not an individual. Philosophically, this places an emphasis on collective effort. Second, Scrum teams prefer not to quantify work in terms of time because this would undermine the self-organization central to the success of Scrum. This is a major break from waterfall: Instead of a manager estimating time on behalf of other individuals and assigning tasks based on conjecture, team members in Scrum use effort and degree of difficulty to estimate their own work.

What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. However, it does ask that teams not estimate in terms of time, but, instead, use a more abstracted metric to quantify effort. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), and even dog breeds, in which a Chihuahua would represent the smallest stories and a Great Dane the largest. The important thing is that the team shares an understanding of the scale it is uses, so that every member of the team is comfortable with the scale’s values.

In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals “show their hands” at once, this process is not unlike a game of poker. Unsurprisingly, teams often call estimation “planning poker.” Some teams have even developed their own decks of playing cards expressly for this process.

Still, even when teams possess a shared understanding of their scale, they can’t help but estimate differently. To arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty, it often requires numerous rounds of estimation. Veteran teams who are familiar with the process, however, should reach a consensus after just a few rounds of planning poker.

Need an example? Watch an example team conduct a Backlog Grooming Meeting, including relative estimation and example user stories. Planning poker is demonstrated at the 4 minute mark of this video:

 
To see how velocity is computed from story points, watch an example Sprint Review Meeting including velocity measurement.
 

Be Sociable, Share!
Comments Feed

Reader's Comments

  1. Aidil |

    I never understood how to estimate, until the third sprint went off the charts…

    Now that we’re in our fourth sprint, we’re still using estimates based on hours, not on effort.

    I’m thinking when we’re done with this sprint, we’ll need to rethink and run our estimates based on effort.

    Thanks, your article has helped shed light :)

  2. admin |

    don’t estimate PBIs in hours! See these great blog posts by Danube about it here:

    http://blogs.danube.com/story-points-as-spiciness-using-rsp-to-estimate-story-points
    http://blogs.danube.com/estimate-by-proxy-not-in-scrum
    http://blogs.danube.com/estimation-game
    http://blogs.danube.com/story-point-estimates-under-estimating-large-items

  3. Scrum-ptious Applications « Matt Jukes |

    [...] for the coming sprint (I’m not going to explain estimating etc for Scrum here – lots of articles about it out there..) This should speed up the process considerably with discussions taking place [...]

  4. Madhu |

    I think the high level estimates must be made before the sprint planning meeting itself. This gives product owner the ability prioritize and take decisions better and at the same time reduce time taken during sprint planning meetings on what needs to go into the sprint backlog from the product backlog. This also ensures that the requirements are as per INVEST criteria. In short, have estimates for the finer product backlog items and not just on the sprint backlog items – just in case you want to replace a story with another story half way through the sprint, the impact is lesser if the stories are of comparable sizes.

  5. Rick |

    So I get the notion of estimating using abstract units. But I run a dev organization that has 14 scrum teams of various sizes (5-9 developers). Many of these teams can get assigned to work on one of the major applications at the same time and as such will be working from the same PBL. How do I forecast my manpower requirements when every team has its own notion of what a story point is?

    Capacity/Manpower planning requires getting some sort of consistent forward looking idea about work velocity, but Story points/ Sprint doesn’t work with multiple teams. How do you get an average effort (speed/distance) when some teams are giving MPH, others KPH and still others using units like furlongs per fortnight? Without having some sort of common conversion unit, or canonical standard, story points are pretty useless for large dev organizations.

    All of the examples I’ve read seem focused on single teams assigned to a single PBL. (Easy… I get it) But there must be someone who has faced this challenge in a larger organization and come up with a method to get consistent sizing from disparate teams..

    Any guidance you might have would be appreciated..

  6. Assembla Tries To Bully Users That Don’t Like Their Product » Absolutely No Machete Juggling |

    [...] A clock? To represent cumulative story points? This re-enforces one of the most common mistakes Scrum teams make, treating points as units of time. Story Points are unitless, not a measure of time. [...]

  7. Adnan |

    great article!

  8. it is not the destination that matters, but the journey you take. « kellrodney |

    [...] team has started estimating effort points and this is awesome for me to get an idea of the scope of work required on a task. Trouble is, our [...]

  9. Scrum, a beginners experience |

    [...] Story sizing consists of all team members sitting around a table with a hand of sizing cards (numbered 1, 2, 3, 5, 8).  A member of the team reads out a story, team members are then asked to ‘play’ a sizing card.  The card indicates a measurement of effort that is not classified in time but by a proportional comparison.  For example if the first story is sized as a 3 (or medium) then a story that is larger and will consist of more tasks may be sized as a 5 or 8.  If a team member’s sizing differs dramatically from other team members the team member will then explain why they consider the story to be larger or smaller and after a discussion a consensus is reached.  Sizing of stories informs the decision as to how many stories will be undertaken during the upcoming sprint. [...]

  10. Nisha |

    I have tried to simplify story point sizing here:

    http://people10.com/blog/2012/02/04/software-sizing-a-mandatory-practice-for-any-agile-transformation-very-simple-and-here-is-how-it-works/

  11. Leyton |

    This post is one of the better ones I’ve seen. The post via the link above from Nisha is even better; of course it’s more detailed too. Its about ordering and sequencing to create more encompassing and clear estimates than time usually provides on its own. Agile is just a different way to get to the same goal; its not to throw the baby out along with the waterfall bath water. There are unfortunately a LOT of PMs out there still that don’t get that; and why I feel like going back to banging my head against the wall now. Thanks for listening. :-)

  12. SR |

    I just joined a new company and I am confused at the way they estimate their stories. I have been doing Scrum for about 4+ years and we always estimated based on the higher value provided by QA and Dev.
    for eg:
    for Story A, if QA says 3 and Dev says 5, we would point that story as a 5.
    for Story B, QA says 3, Dev says 3, Story point is 3.

    In the new company,
    for Story A, if QA says 3 and Dev says 5, we would point that story as a 8.
    for Story B, QA says 3, Dev says 3, Story point is 8.

    They are basically adding 3+3 and accounting it as a 6 which ends up as an 8 point story since we use the Fibonacci series.
    Can anyone tell me which is the right way?

    thanks,
    SR

  13. Why use Fibonacci in planning poker ? |

    [...] more details [...]

  14. Why use Fibonacci in Scrum poker ? |

    [...] more details [...]

  15. Better Sprint Planning through Time Tracking | the Intervals Blog by Pelago |

    [...] are defined by the number of weeks they will take. Agile development practices recommend planning sprints lasting two, three or four weeks. Since we are designating the length or our sprints using units of [...]

  16. Rain Drops » Scrum (development) |

    [...] ^ a b “Scrum Effort Estimation and Story Points”. [...]

  17. 12 Points ! L’utilisation des Story Points en mode Agile | So@t blog |

    [...] simple, mais en même temps assez pratique pour s’organiser : certaines équipes utilisent les tailles de t-shirts (XS de XXXL), d’autres la suite de Fibonacci (1,2,3,5,8…). Parfois on commence avec les [...]

  18. Task Estimation: The Why and the How - Chris Steele on Agile |

    [...] I want to be clear, and state that not everyone does task estimation and breakdown the same way. That’s ok. In fact, I love that. I think it is a great [...]

  19. Metrics, Plumb Lines, and System Thinking « Codecraft |

    [...] simple competing metric pair will suffice. Measure how quickly your team adds features (e.g., with story points), and measure how much your quality suffers (e.g., with a variant of containment rate), and [...]

  20. Vinay D Bhagat |

    Hello,

    Please help me to estimate the documentation effort accurately in the agile environment.

    How to estimate documentation effort in the agile environment?

    How many days of documentation effort do we estimate for 1 user story point?

    Is 2.2 hours per user story a good estimate. Time spent in meetings (3 hrs a day).

    Example 1:
    User Story Points: 220

    Documentation Effort (in hours): 484 hours

    Documentation Effort (in days): 72 days

    Example 2:
    User Story Points: 220

    Documentation Effort (in hours): 440 hours

    Documentation Effort (in days): 55 days

    If we have documentation 1 to 2 defects coming per week, how do we estimate this defect resolution effort?

    How do we estimate for the following factors affecting documentation effort estimation?

    * Gathering inputs from the SCRUM team (usually do not get inputs in time)
    * Getting product documentation reviewed from the SCRUM team (lot of email exchange and follow up to get the SCRUM teams approval by email and by review tool)
    * Last moment updates to the legacy content (in the last 4 to 7 days before final product release date)
    * Time spent in meetings (3 hrs a day)
    * Sickness of the writer and the SMEs
    * Strikes and natural calamities

  21. theamericanspring |

    Your Fibonacci Sequence is incorrect in your article. It should be:

    0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…

    or alternately,

    1, 1, 2, 3, 5, 8, 13, 21, 34, 55…

    Just wanted to point that out in case anyone wanted to use it for their estimating scale.

  22. admin |

    Technically, you are correct, there should be two “1″s in a Fibonacci sequence. In Scrum’s case, both these represent points or effort, so they are the same, so we use a shorthand and don’t include both of them.

  23. Anil |

    @SR : You described following effort estimation used at your past and new company as below :-

    PAST:
    for Story A, if QA says 3 and Dev says 5, we would point that story as a 5.
    for Story B, QA says 3, Dev says 3, Story point is 3.

    In the new company,
    for Story A, if QA says 3 and Dev says 5, we would point that story as a 8.
    for Story B, QA says 3, Dev says 3, Story point is 8.”

    For every user story effort estimate is done, so it can not be OK if we say take Dev story point or QA (and also Summing up both story point is totally WRONG). Each user story might have different impact for
    QE , DEV and not to forget other team like Localization, Documentation team ,UI , build engineer etc ( if it is applicable in your company). I understand usually in most of the companies there are Dev/QA who do story pointing.

    So now coming back to story pointing; let everyone (irrespective of their role in scrum team ) in team give story point (we say Vote). It is recommended that all should vote even though some people might not be working for that user story . And best practice is that user story should be clear to evryone and hence all should vote (not a single vote by Dev and QE). We use a Voting tool (poker card)where we see all votes but not who vote what. Voting should not be biased and planned.

    Here are different cases :-

    1) Most of the team members vote almost same but 1 : Let’s say points are 3,3,5,3,3
    Now obviously it looks like Story point should be 3 but again we need to LISTEN to person who voted 5. Might be he have very valid justification for 5. If not, other will convince for 3 after consensus we can have ’3′

    2) Huge difference in story pointing ; 3,3,3,20,20,20
    In this case Min is 3 and Mac is 20. So there could be 2 way ; 1st by just consenus decide to 3 or 20 or do story pointing again.

    3) There could be instance when Dev say 3 and QE say 40. This could be possible ; e.g. might be Dev 1 LOC change but QE need to retest all workflow and do regression. So discuss and agree to to 3 or 40.

    In summary, story pointing vary from company to company, but effort estimation is learnt by practice/experience. In few sprints, you might give incorrect estimation (which you miss) but with time you will start having correct effort estimation and hence will be reaping SCRUM’s benefit with Timely delivery and happy customer :)

  24. Anil |

    @ theamericanspring
    For effort estimate, it is not necessary you exact use Fibonacci series. You can use t-shirt size XS, S, M, L, XL, XXL, XXXL (as mentioned in doc).

    But we use Planning poker sequence 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 . see http://en.wikipedia.org/wiki/Planning_poker

  25. Michael |

    @admin, thanks for posting this, it was very informative.

    I’m with a company that currently scores points of work effort on both stories in the product backlog as well as points of work effort for action tasks for our sprint backlog. I’m currently confused about the 2 as this is different to what I’ve learnt in scrum training a year ago.

    Looking for a bit of guidance as of exactly what the term “action tasks” mean in scrum and how it should be scored?

    Thanks.

  26. MJ |

    I’ll give my opinion on Michael’s question. The most experienced team I know went for a couple years using story points for PBIs and hours for tasks, which were always about a day or less. Eventually they got tired of measuring hours for tasks, so now they just track tasks without putting hourly estimates on them. Tasks are just for the team to track their own work during the Sprint so stuff doesn’t fall through the cracks. There’s no point in getting to formal about them.

    BTW, I don’t think “action task” is a standard Scrum term, but we do expect teams to come up with their own implementations so maybe it’s useful for your team.

  27. Michael |

    Thanks for your opinion MJ,

    I was recently reading this article http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms on scrum terms and that’s where I came across the idea of “Action Tasks”, not too sure if this is the defining term, I’m sure every scrum team would describe that differently.

    Based on your reply above, my underlining question is, is scoring “Hours” on tasks the the conventional framework of scrum or am I completely off the tracks here?

    The reason why I ask is that currently, what I’m experiencing in my scrum team is that we currently have multiple projects within one team. This means that we have to prioritise stories from different projects along with their tasks in to fit into our bi-weekly sprint. We are currently scoring each task with points worth of effort rather than hours and this confuses me as I read the article on this website and it states “Scrum refuses to quantify work in terms of time”.

  28. MJ |

    Some history: When that glossary was written most of us were going by Ken Schwaber’s first two Scrum books, which did actually use hours for tasks (and possibly hours or days for PBIs, but I don’t remember anymore). Around the same time Mike Cohn published _Agile Estimation & Planning_ which helped popularize the relative estimation techniques he’d seen used. Back then (years ago) we actually asked Mike Cohn whether our own team should also use relative estimates for tasks and he suggested tasks were simple and small enough things that using absolute hours should be fine. After that we noticed other teams had stopped estimating tasks at all — just kept them 1 day or less and simply count them if a Sprint Burndown Chart is desired.

    Unlike Product Backlog Items (PBIs), tasks are just there to aid the team’s self management. The team commits to the Sprint goals, acknowledging that the tasks to achieve them will probably vary. Ken’s second book observed that around half the tasks to achieve the goals aren’t even discovered until during Sprint execution. I also heard him suggest it wasn’t really appropriate for outside managers to be scrutinizing the Sprint burndown chart, as the team is supposed to grow into a self managing entity.

    Fast forward to 2013: Ken Schwaber’s latest Scrum Guide does not even specify that teams use tasks at all. Product Backlog Items (PBIs) (typically user stories) are still with us, because those are part of the team’s interface to the Product Owner and the outside world. Teams found many variations that worked for them, including making the PBIs so small that tracking tasks was superfluous. There are even folks who advocate not estimating user stories — just split them until they’re small (like 2-3 team days) and count them.

    So I guess there’s no official Scrum answer on this anymore. Ken and others are explicit about something else though: a self organizing team focusing and collaborating on clear goals. We won’t get that extra self organization boost if we’re not pulling together on one thing, or losing momentum with a lot of context switching. The one time I was on a team juggling several projects in one Sprint we didn’t really collaborate the same way we did when we were working on one product at a time. If I had to do that again, I probably would prefer more traditional capacity planning using hours.

    If you think working on three projects may be affecting your team focus, I wonder if you’d consider doing shorter Sprints, each dedicated to one thing at a time? Maybe one week for Project A, and another week for B and C? Limiting Work In Progress (WIP) in this manner may force your team to find new ways to collaborate.

  29. Anita |

    I’m wondering about the area near 4:55 of the video, where the Product Owner is there to clarify what he wants, even though in the article, the writer specifically states that he recommends NOT having the PO there for the estimation meeting.

    Or, is the author trying to demonstrate an example where, if the team members can’t agree on a value for the item, the PO should be consulted?

  30. MJ |

    Anita, in my opinion the benefits of having the Product Owner attend backlog refinement nearly always outweigh the disadvantages. Our views have shifted after observing many teams since we wrote the main article above. I’ve updated the article accordingly. Thank you for pointing out the inconsistency.

  31. Make Sweeping Changes in Code | Topics in Software Engineering |

    [...] a rough estimate with stories and story points, I spent about 8 points to design and develop a replacement component based on the updated library, [...]

  32. Kristian Nissen |

    We use story points in order to estimate stories, the problem is; how do you turn something like Chihuahuas into a release plan you can present to your projects steering committee?

    You need to know how many story points, or as I like to put it “How many Chihuahuas can you burn on any given day?” which brings you back to people often turning story points into hours they expect to sit at their desk, focused on writing code in order to meet some expectations.

    I think there is a missing link between the scrum process with the agile development process used at the execution level, to the reporting done at a meeting with your steering committee. How do you translate Chihuahuas so that some one from the world of marketing can understand it?

    It shouldn’t be necessary to convert the entire business into an agile one, in order to make this work for IT.

  33. MJ |

    Kristian,

    I sense a contradiction in “agile development process used at the execution level, to the reporting done at a meeting with your steering committee.” One of the 12 principles in Agile’s definition states “Business people and developers must work together daily throughout the project.” Scrum is not intended to be for “execution level” and steering is done by a Product Owner rather than a committee. Stakeholders who are really interested in what is going on will learn more in less time by attending a Sprint Review Meeting to see a live demo of the product rather than a status report full of made up estimates — estimates for software projects are notoriously bad, but that’s a topic for another post.

    All that said, and acknowledging there’s some inherent necessary unpredictability, we can use Scrum/Agile to eliminate the unnecessary unpredictability and sometimes get more useful forecasts than we were getting before. Example ways to reduce unnecessary unpredictability: keeping the team constant, keeping the Sprint length constant, using TDD and Continuous Integration to keep the product in a shippable state at all times. Mike Cohn’s book Agile Estimation and Planning covers forecasting at length, or you can read a brief summary of macro-measurements.

    In general, Scrum Product Owners prefer to hit fixed and frequent release dates while constantly choosing the highest priority things to work on. If we’re doing all this right and we get our estimates wrong, we leave out the lower priority features… generally a less painful failure mode.

    Hope that helps.

    –mj
    (Michael)

  34. Story Points and estimating in Scrum. Confusing? |

    […] will require, relative to other User Stories. The guys at Collabnet have written an article on Scrum effort estimation and story points that you may like to […]

  35. Sachin |

    Back to basics:
    From the example above (SR)
    for Story A, if QA says 3 and Dev says 5, we would point that story as a 5.
    for Story B, QA says 3, Dev says 3, Story point is 3.

    Here when QA is saying 3 she is considering the QA efforts only as she may not have an idea of the dev efforts and same is the case with Developer so it would be 5 + 3 ?
    Or being a multi-disciplinary team it is expected that QA understands the dev efforts as well and when she is saying 3 it covers dev + QA ?

  36. MJ |

    Sachin, yes, the idea is that the team members learn to understand each others concerns. If we also use a test-driven development approach and pair programming, it’s likely that those two people would be collaborating in real time rather than handing the work off from one to another.

  37. Ted Johansson |

    Reading some of the comments, it becomes clear that a lot of organisations don’t track team velocities. This becomes blatantly clear from questions like:

    “If they estimate in points, how do I know how long it will take?”

    If you know the velocity, and you know the total effort in points, the calculation is trivial.

    The benefit of using points over hours is that two identical tasks will always have the same estimate. If you estimate in hours, the estimates will keep getting lower as the team’s velocity increases, and it will look like the velocity is constant. We want to, instead, keep the estimates constant, to easily track the change in velocity.

  38. Srikanth |

    Hi,

    I have a question related to the story points.

    Can a story be re-estimated and re-sized if it is carried forward to the next Sprint? For example, if we have a story which the team initially estimated as 3 pointer, but during the sprint the team understood that the estimate was wrong and finally the story was failed. While the story is moved forward to the next sprint, can we re-estimate the story points and make it 5 or 8?? Is it the right way of doing the agile?

Leave a Reply

Scrum Training Courses