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 refuses 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 the team’s velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. 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.

Share and Enjoy:
  • Digg
  • del.icio.us
  • DZone
  • Google Bookmarks
  • Technorati
  • Sphinn
  • Mixx
  • blinkbits
  • blogmarks
  • Blogsvine
  • Blue Dot
  • Fark
  • Furl
  • Linkter
  • Ma.gnolia
  • Netvouz
  • Spurl
  • StumbleUpon
  • TwitThis
  • YahooMyWeb
  • Bumpzee
  • HealthRanker
  • MisterWong
  • Reddit
  • Fleck
  • Gwar
  • Kirtsy
  • LinkedIn
  • NewsVine
Comments Feed

Reader's Comments

  1. Aidil | October 6th, 2009 at 4:24 am

    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 | November 6th, 2009 at 1:16 pm

    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 | January 20th, 2010 at 2:10 pm

    [...] 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 | January 26th, 2011 at 11:12 pm

    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 | February 17th, 2011 at 5:31 pm

    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 | September 8th, 2011 at 10:32 pm

    [...] 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 | October 21st, 2011 at 9:11 am

    great article!

  8. it is not the destination that matters, but the journey you take. « kellrodney | November 23rd, 2011 at 10:11 am

    [...] 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 | November 23rd, 2011 at 7:16 pm

    [...] 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. [...]

Leave a Reply

| Scrum Methodology | Scrum Training | Scrum Software | Scrum Tools | Scrum Master Certification | About Us |