The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.

Scrum Effort Estimation and Story Points

Submitted by admin on Fri, 11/21/2008 - 14:30
Anxiety about estimation usually means the organization is not strong in the other Agile practices such as Test Driven Development (TDD). Scrum requires that the product be kept in a potentially shippable (e.g. properly tested/integrated) state every Sprint, that the Product Owner declares which work is top priority, and that work be split into thin vertical slices, typically customer-centric user stories no bigger than a few days each. If we're doing the other Agile stuff right, we cannot miss release dates because the product is shippable every week or two. The only downside of getting estimates wrong is that we'll ship on time while omitting the less important features -- a less stressful way to live than what waterfall or pseudo-Agile teams are experiencing today. In waterfall, managers determine a team member’s workload capacity in terms of time. Managers ask selected developers to estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time. In waterfall, tests are done after coding by specific job titles rather than written in conjunction with the code. The downsides of waterfall are well known: work is always late, there are always quality problems, some people are always waiting for other people, and there's always a last minute crunch to meet the deadline. Scrum teams take a radically different approach. First of all, entire Scrum teams, rather than individuals, take on the work. The whole team is responsible for each Product Backlog Item. The whole team is responsible for a tested product. There's no "my work" vs. "your work." So we focus on collective effort per Product Backlog Item rather than individual effort per task. Second, Scrum teams prefer to compare items to each other, or estimate them in relative units rather than absolute time units. (Ultimately this produces better forecasts.) Thirdly, Scrum teams break customer-visible requirements into the smallest possible stories, reducing risk dramatically. When there's too much work for 7 people, we organize into feature teams to eliminate dependencies. What does the process of estimation look like? Scrum does not prescribe a single way for teams to estimate their work. The only estimate that's defined by Scrum is whether a team will attempt a PBI this Sprint or not, as decided in the Sprint Planning Meeting. Common estimating methods include t-shirt sizes (S, M, L, and too big), powers of 2 (1, 2, 4, 8), the Fibonacci sequence (1, 2, 3, 5, 8, etc.), or simply small vs. needs-to-be-split (see #NoEstimates below). In the Backlog Refinement Meeting, the team sits down with the Product Owner to discuss the stories toward the top of the Product Backlog. The Product Owner often wants effort estimates to help evaluate ROI, effectively prioritize items in the Product Backlog, and predict which items will be ready by a given release date. So the Product Owner wants an honest appraisal of how difficult work will be. To gather a cross section of viewpoints despite the different personalities on a team, it is often useful for all team members to disclose their estimates simultaneously. Individuals show their cards at once, inspiring the term “planning poker.” Individuals will usually choose different cards. This should trigger discussion of the implementation approach, clarification of the requirement with the Product Owner, and splitting the requirement into smaller stories (some of which will be lower priority). Often several rounds are necessary to arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty. The refinement and clarification are more important than the estimates themselves. According to the Agile Manifesto, business people and developers must work together daily throughout the project.

#NoEstimates Controversy

In recent years, teams subscribing to the #NoEstimates philosophy have simply made all stories as small as possible. For #NoEstimates teams, the only estimate is whether a User Story is small. If it's not small, they split it until it is small. Some of these teams still make forecasts by comparing completed stories over time to stories remaining in the release plan. The #NoEstimates approaches are gaining ground, but not universally accepted within the Agile movement.

Interfacing With Traditional Expectations

For techniques that may be more palatable to traditional managers, see Mike Cohn's popular book Agile Estimating & Planning. Our own team used some of these approaches to make multi-month forecasts and release plans. They were still a bit off, but they were closer than anything I'd seen before. One thing that helped was doing everything possible to eliminate unnecessary unpredictability. Product development is ultimately about learning and creating, so some unpredictability is necessary. But unnecessary unpredictability can often be reduced by keeping the same team together, keeping the Sprint length the same, always building end-to-end integrated vertical slices, eliminating external dependencies, and using techniques like TDD to avoid surprise regression failures and interruptions. Bad code causes painfully unnecessary unpredictability in waterfall or Agile. If you're wondering how to make all this work with contracts, I'd urge you and your lawyers to read the Agile Contracts Primer.

About The Author

This article was rewritten by Michael James, an Agile coach based in Seattle (but often found in other cities). Follow MJ on Twitter or LinkedIn.


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.  


I'd be interested to know how you estimate a product launch. Often you don't yet know the teams velocity and you haven't broken every story down into small enough stories to accurate estimate them, but you still need to know if the product could be build in 3 months or 6 months or for $500k or $1m when you start the project. I'd be interested to know what techniques are used to estimate a product launch and cost, when you don't have the luxury of breaking every story into small stories at the start.

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 :)

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

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.

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. :-)

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?

@ 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

@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 :)

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 ?

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.

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

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.

Thanks for your opinion MJ, I was recently reading this article 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".

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.

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.

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?

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.

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)

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.

Hi Srikanth, We are doing agile methodology from past one year and we have re-estimated and re-sized when the intial estimate faild for the user story. Because we learned more on it and had to re-estimate on it. We are working with the company who call themselves as the best agile developers so to answer you looks like it is right approach. Hope it helped you.

Grant, yes, that's a good topic. I'd advise anyone in a situation like that to read Mike Cohn's _Agile Estimating & Planning_, which was very useful for our team when it came out. I'm also thinking I should update this article to show some of the hybrid techniques we found useful when we were in imperfect situations.

Excellent Article. I am doing research work on similar methods, I need some authentic datasets for agile estimation. Can anyone help me know the sources from where I can get? Please reply

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.