Get certified - Transform your world of work today


Why Sprints Should Be Planned with Hours, Not Points

For anyone who has read my book, Agile Estimating and Planning, it should come as no surprise that I'm a big proponent of using story points to estimate a product backlog and for medium- to long-term planning. What you might not know, though, is that I do not recommend using points or velocity to plan a sprint.

To help explain why, let's consider an American football team, say the Denver Broncos. Let's suppose that halfway through the season, the Broncos statisticians calculate that the team has scored an average of 21 points a game. It is entirely appropriate for the Broncos to predict that the team will continue to average around 21 points a game for the rest of the season. It is not, however, logical for the organization to assume that the Broncos team will score exactly 21 points in the game this Sunday night.

Similarly, it is appropriate for a development team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we should commit to 20 points for this sprint.”

Points are too imprecise to be useful in the short-term. They need to averaged over at least a handful of sprints to become useful predictors. Velocity changes from sprint to sprint—usually not wildly, but it does vacillate. Teams, therefore, should plan their sprints by looking at the product backlog, selecting the one most important thing they could do, then breaking that product backlog item (user story) into tasks and estimating those tasks in hours. If a team can commit to delivering that product backlog item, the team brings it into the sprint. If the team cannot (that is, if the sprint is full), then the item is left in the product backlog. In other words, the team only commits to the stories it is capable of completing in a particular sprint.

In this type of commitment-driven sprint planning, teams don't need to discuss story points or velocity. Instead, they need to determine which items they can complete in the coming unique sprint. After planning a sprint this way the team can add up the story points on the items they’ve selected for the sprint—that should be reasonably close to their average velocity. (Product backlog items should still have been estimated in story points so that stories can be prioritized and longer-term plans made.) But because of the imprecision in any story-sized estimates, the sum will not always be exactly the team’s average velocity.

Do you want one short tip each week from Mike to help you succeed with agile?


Article Rating

Current rating: 4.2 (46 ratings)
Smita Sinha
I Respect your View Mike but I differ. User Story can be in Story Points and task in hours as JIRA OR TFS also supports the same. Sprint planning can be based on Story points or Committment driven or preferably combination of both , For me Story points or combination of Story point / committment works well ( depend on team dynamics ). I prefer changing Sprint planning way after some interval so that Team is focused on value rather than story point or hours .
1/16/2018 7:58:32 AM

Mayuri Patel
I think that you have to estimate with what works best with each team. I used hours for each task with an infrastructure team because they had tasks which were estimable in hours and had a board that was a cross between Scrum and Kanban (we called it Scrumban). It worked very well for the team, but more importantly, promoted the principles of agile to help the team improve the team's productivity. On the other hand, I used story point estimation for other teams that I had and it worked well for them. As mentioned in a previous comment, when a team is in the forming/storming stages they are not precise with their estimation but as they complete more sprints they become more familiar with the estimation and it becomes second nature for them to estimate how many story points they are able to complete in an iteration. The more you work with teams, the more you see how no two teams work the same so the velocity and estimation will also be different for each team. The hardest part is finding what works best and getting there! So, in agile you try different ways until you find a way that works.
5/18/2017 6:31:33 AM

I tend to use story points as a guide to make sure we have enough work in a 'ready to work' state prior to the sprint start. If we have the 'average velocity + 20%' ready to work then we are probably in good shape for the next sprint
8/26/2016 10:10:21 PM

Amanda Paul
Planning undertakings ought to be perceived and approximated amid variant get ready and included to the adaptation system, despite the fact that they won't be connected with a story that is being outlined in the present emphasis
6/4/2016 6:49:58 AM

Andrew Boothroyd
I have a number of concerns with this approach and the justification for it:
1. using both points (for long term planning, prioritisation, velocity and tracking) and hours (for estimation) diminishes the efficiency benefits of using points as an abstraction

2.The analogy of the basketball committing 20 points based on average score to date shows that they should perhaps commit to slightly less than the average. It isn't the measurement system that is at fault here, and has no bearing on points vs hours. It is a bad analogy.

3. There are many reasons why hours/days are also imprecise in estimation too (e.g. different developers and levels of experience). The statement "But because of the imprecision in any story-sized estimates, the sum will not always be exactly the team’s average velocity" implies that all variances in relating time based estimates to average velocity are due to points based imprecision on stories, which is not true.

4. The distinction between short and longer terms affects estimation irrespective of how it is measured. In early sprints without much history to calibrate the estimation, there will be more inaccuracy. It would be better to err on the side of caution rather than to place the emphasis on changing the unit of measurement.

I have heard arguments for and against points vs time. Irrespective of which argument you accept, I believe it is best to commit to one or the other. If you are comfortable with points, then I believe they should be used exclusively. If you aren't, then don't use them.
2/15/2016 4:10:43 AM

Mike Cohn
If it's working for you, don't change a thing. Be prepared, however, to change things as soon as someone new joins the team.
12/30/2015 3:15:34 PM

Manoj Sanhotra
Hi Mike,
Our team is quite matured, have great application knowledge, all programmers more or less have same level of experience and expertise and the team composition hasn't changed for quite long. With that level of maturity, we don't use points or hours for our sprint planning. Since team member has a good understanding of each product backlog item, each developer commits to certain number of PBI's for the sprint. Eventually, we have list of all PBI's that our DEV team have committed to for this sprint. QA takes a shot at this list and commits if they can also support these PBI's. If required, the list of adjusted. In this exercise, each team member has already taken into account their available bandwidth for this sprint (day offs and time for admin/non-project related work). So effectively, its all based on what team thinks they can deliver (gut). We sum up the points and that's our sprint goal. Which more or less is close to our velocity. What do you think about this approach?

Thanks !
12/23/2015 8:48:45 AM

Rene de Ruyter
I am moving away of planning with (effective) hours. The planning sessions take much longer than while estimating in relative sizes like story points.
The tream will learn how to do better normative story point estimating when they see the velocity deviates a lot from Sprint to Sprint. I do not see this happening when planning with hours. The debate also becomes 'uglier' and it becomes harder to keep the team spirit up.
Also it takes more time to first do storypoint estimating and then still do a hour estimation. It's twice the work. And my team thinks it eats up too much of their time an I tyhink they are right.
For me the simplest an most effective of estimating is still using story points.
Like you state in your book, you need to get hour estimates for the parties outside of your Scrum teams for a lot of different reasons.
12/14/2015 3:56:57 AM

Mike Cohn
Good points, Sahil.

I agree, Dave. I always some percentage (20% sounds good) beyond the current velocity close to ready to go.
11/4/2015 7:32:57 AM

I tend to use story points as a guide to make sure we have enough work in a 'ready to work' state prior to the sprint start. If we have the 'average velocity + 20%' ready to work then we are probably in good shape for the next sprint.
11/4/2015 6:51:01 AM

I agree with this article, and I also prefer using hours for nearer term more accurate planning. This is because most teams, especially those new to scrum, intuitively think of 'estimate' in terms of hours, and then they have to duplicate the effort by converting hours into equivalent story points just for the sake of having story points. As the team matures, perhaps they would intuitively estimate in story points. One more difference in selecting a suitable approach I have found is that story points is more suitable for a product-based organization and hours approach for a services-based organization. This is because in a services organization, clients keep changing, and all clients are not familiar with the scrum concept. They will always ask for status updates and schedules in hours and days. So the service provider team working in scrum will anyway have to work it out in hours. This is just based on my experience so far.
11/3/2015 12:03:21 AM

Philip Nicholls
I agree with Andrew Bignell. Points has worked ok for us too, and the team seem comfortable with commitment to the stories prioritised by the PO. It has taken a long time to get engineers to look back at relative complexity in stories in order to points estimate new stories, it would be impolite to then say forget that for the next sprint and let's work it out in hours what we can do. Predicted Velocity start point is an average (10 iterations for me) and it can be adjusted if I think the team will be hit by excessive absence, e.g Summer holidays. We sometimes use hours to task out in part 3 of planning but this is used to demonstrate outstanding effort during the sprint burndown. It can be more realistic than points, but not always, for example if there are three stories in play, each close to finishing, but each is 5 points and 300 hours. In this scenario, we'd have 15 points to burn up, but possible only 20 hours to burn down. I know other organisations that don't use hours, full stop (period).
Secondly, I'd be nervous recommending the team task out a story in hours only to find it was too big to fit in the iteration after all - this would be a waste of effort.
7/28/2015 7:27:29 AM

Mike Cohn
You're welcome, Nuwan.

Yes, this is definitely a gray area in Scrum. Or perhaps, better said, it's really just an undefined area in Scrum. And, as you say, many teams try different approaches. That's actually the beauty of Scrum--that many things are left undefined and it is up to the team to figure out what is best for them while working within the Scrum framework and being true to the principles of agile.

I'm definitely in agreement with you that estimates on the product backlog should not be converted to hours. It creates confusion and product backlog items are a little too large to really be in hours.
7/26/2015 11:43:20 PM

Nuwan Gurusinghe
Hi Mike, thanks for sharing your thoughts, this is bit of an grey area in scrum and often many teams try different approaches. I usually go by hours in planning the sprint and it helps to measure the exact commitment the team can make in the sprint, but as you mentioned the product backlog can still be based on story points though some of my team mates argue it should be converted to hours as well which I believe not necessarily needed
7/7/2015 4:11:24 AM

Sonal Bajpai
Nice Article!!! I liked reading through and believe me, SCRUM itself is a methodology used to reduce complexity but story points estimation increases the complexity of the whole process. It is indeed difficult to estimate in story points and at the same time deciding the delivery of project with velocity.I have been doing story points estimations and at end of day every thing is measured in time. While the estimates are not actual why not use hours for estimations.
6/12/2015 7:02:48 AM

Mike Cohn
Thanks, Ravi.

Please note, though, that although I like planning sprints with hours, I am probably the world's biggest fan of planning with story points--but story points are only useful over a handful of sprints with the imprecision innate to them is able to average out.
3/19/2015 5:15:00 PM

Ravi Narla
I like this idea. I was very comfortable estimating a story in terms of hours than points. I was always told that points don't mean number of hours and it respresents the magnitude of the task at hand measured in Fibonacci series or T shirt sizes. When the time taken to complete a task that is sized M or 5 points differs with the same sized task in a given project there is clearly a inaccuracy. If the effort taken to complete a task varies why not measure in terms of hours which gives a precise estimation. More often even after estimating a Story point the number of hours taken to complete the task is never revealed and exact time taken to burn the tasks cannot be calculated accurately. This is my opinion based on my 5 years of experience in Scrum.
3/18/2015 8:37:57 AM

Al Marvin
Story point estimation is pretty bad despite what the experts say.
I’ve never seen it go accurately, maybe if you’re doing web pages. Anything complex it falls apart.
You ask anyone to estimate work, they intuitively think in hours. Then they convert that to points. Every time you add a step to any mathematical operation your adding errors. Basics.
Can anyone comment on when story point estimation worked for them developing.
1/21/2015 2:56:23 PM

Mike Cohn

I am describing a process known as "commitment-driven sprint planning," which I've more fully described at

In that approach the team doesn't use points or velocity. They just plan with hours. At the end of the planning meeting though they can add up the points that were initially put on each story as part of product backlog estimation (your question) and the sum of the items committed to the meeting should be somewhat close the the average velocity. If not, that's a sign that the team might be over or under-committing. (Or that an item was poorly estimated.)

In general, I'm not a fan of re-estimating except under a couple of circumstances. You can read more about that at

I apologize for pointing you to other posts but when I've addressed things fully elsewhere I find that better than giving partial answers all over the place. I hope that's OK.
1/18/2015 10:05:35 PM

Michelle Jensen
Mike - Can you elaborate a little more on this idea: "After planning a sprint this way the team can add up the story points on the items they’ve selected for the sprint—that should be reasonably close to their average velocity. - See more at:" Are you referring to the original points assigned during the product backlog estimation? If yes, can the team update or correct PB task/user story points upon completion of the sprint?
1/15/2015 2:00:33 PM

Mike Cohn
Hi Adriaan--

It's not so much that any magic occurs because of changing units. Rather, I advise teams estimating product backlog items to do so very quickly--targeting about 20 items estimated per hour. So that's only about 3' on average per user story.

In sprint planning the work is discussed at a deeper level--perhaps 10-15 minutes per story. I would expect that to result in more precise estimates.

Your comment seems to say the same thing--e.g., you wrote "once a story is defined well enough." Three minutes (on average) is "well enough" for a ballpark estimate that will average out with a bunch of other product backlog item estimates, but it's perhaps not "well enough" to be yet brought into the sprint.
12/13/2014 2:15:09 PM

Adriaan Koster
Hi Mike,

Thanks for the insight. The bliss of using storypoints is that it avoids the suggestion of accuracy caused by estimating in hours. Your article suggests that extra accuracy will be found through with the additional up-front effort of splitting a story into tasks and estimating those tasks separately, in hours. In my experience this is not the case. Once a story is defined well enough (i.e. so that splitting it up into subtasks would be feasible) the combined estimation powers of the development team usually seems to be sufficient. Of course there are also unexpected hurdles but these won't show up by a different estimation process based on the same information.
12/9/2014 4:49:28 AM

Andrew Bignell
I have to disagree. I think going back to asking the team to think in hours, unravels everything we have been preaching as scrum masters and coaches. It is hard enough to win the battle over why we don't estimate in hours and use story points, now we might have to ask to think both ways? We know that points are inaccurate, but they protect the team and that's partly why we use them. Yes velocity does fluctuate and so it should, but what we do is use our average velocity over the last 3 sprints and that is what we will commit too. Do we hit our target every sprint? No, but we get close, sometimes we take a story mid sprint as we make good progress. Overall the article is an interesting perspective and since it comes from such a reputable source as Mike, should be studied. Since Scrum is not totally prescriptive, teams can either experiment or not, that's the beauty of Scrum. For our team, i feel that confusing the team with thinking in points and hours would only go as far as having them think that a 3 point story is therefore x hours and a 5 point story y hours. I'll stick with points since it is working for us right now, but thanks for the perspective.
11/11/2014 9:24:11 AM

Mike Cohn
Hi Hussein--

That sounds like a good approach and certainly keep with it since it's working for you.

One thing to keep an eye on, though, is whether it is too conservative, leading you to consistently under plan sprints. That's possible since you stop when either this or that is true--it makes you a bit more likely to stop too soon. That isn't the worst thing, just something to keep an eye on.
11/9/2014 2:04:59 PM

Hussein Aly
I agree with your article, but here what Our team is doing.
The team keeps pulling items from the back log till one of the two conditions is reached. 80% of capacity is reached or team velocity + 5% is reached.
11/5/2014 3:06:37 PM

Mike Cohn
Hi James--

Teams do pretty much need to start with commitment-driven sprint planning since (as you say) they have no historical data. From there, some teams use velocity to plan each new sprint.

I don't think that works well because velocity is too variable. My experience is that velocity on a good, experienced team will bounce around in a plus / minus 20% range (relative standard deviation). So a team averaging 20 could easily get 16 one sprint and 24 the next and have that just be random variation in velocity.

I am the world's biggest fan of story points and velocity but only when used to plan over at least a handful of sprints. When doing that, things average out and velocity works extremely well. For a single sprint, I want to plan that as described here.

By the way, keep an eye out on my personal blog at On Tuesday I'll have a new post there explaining fully why I prefer commitment-driven sprint planning over velocity-driven sprint planning.
11/2/2014 8:00:00 PM

james farrer
Hi Mike,
Just about to start reading your book.
I like the idea of commitment based estimation for teams that are new to agile. But saying this, I thought this was only used to get the team going over a number of sprints until they started generating a good velocity. To use an individual sprints velocity to determine the amount to work to take into the next sprint would be ridiculous. I thought the average velocity is a guide to determine if the team can take the work into a sprint. If the team are continuously inspecting and adapting, then they can learn from past errors in over committing.
Pretty gutted to read this, but maybe I've interpreted this post :)
10/16/2014 8:22:38 AM

Mike Cohn
Hey Ryan, that's unfair using my own blog post against me! ;)

I can hold both of those views because I try to do sprint planning much faster than most teams I encounter. Sure, a few teams I meet need to spend more time in sprint planning but the vast majority spend too long on it.

Sprints can be planned any number of ways so, sure, points can be precise enough. So can random guessing. However, a team planning a sprint with points will be less likely to finish all of the work they brought into the sprint. This has largely to do with the imprecision of points. A story called a 5 could be a 4 or a 5. (I'm assuming the team treats the points like buckets as I advocate.) So when they bring that work in and count it as 5, they may be bringing in the wrong amount. (It could also be a 6, a 2 or a 43 if they mis-estimated, of course.)
10/9/2014 9:28:48 AM

Mike Cohn
Hi Shane--

I suspect I haven't been sufficiently clear. I have not demonized velocity. I consider myself the world's biggest fan of velocity and story points but they are best used for making predictions over at least a handful of sprints. They are not sufficiently precise to be used for planning a single sprint.
10/8/2014 7:56:47 PM

Shane Tanzymore
Good article. While points are not great for Sprint planning (team capacity is in hours and can fluctuate), I would not go as far as you and Jai go in demonizing velocity. I've found using the run rate over 3+ Sprints is an effective entry point into planning. This has helped frame the discussion, especially for a team working on several efforts.
10/8/2014 8:43:20 AM

Prasanthi Nunna
Hi Mike, I agree with you. Especially when an Organization is new to Agile, in the transition time it is very good to Estimate using hours.
But i experienced in some Organizations where they are really good at creating small backlogs, providing proper Story Points then Story Point Estimation worked really well.
10/6/2014 9:42:51 AM

Ryan Henderson
I disagree. In my opinion, points provide enough precision for sprint planning. Using this article as a guide (, I would argue that the cost of coming up with hour-level estimates is too high for the slightly-more-accurate estimate it gives you.
10/3/2014 9:23:28 AM

Mike Cohn
Thanks, Bob. I'm glad we agree.

There are some very fundamental problems with Ideal Days. Mostly that two developers will never agree on how much can be done in an "ideal day," because they each produce at a different rate.

Many years ago, I worked with teams experimenting with a way to get around that. We used "Experienced Senior Programmer" Days. (ESP Days was a perfect acronym for estimates!) The idea was that we had defined an experienced team member and estimated how long it would take that person to do the work.

That got around the "my time isn't your time" problem but created a new problem in which each team member was estimating not for themselves but for someone better or worse than themselves. In some ways, that made estimating harder.
10/2/2014 12:16:43 PM

Mike Cohn
Hi Pedro--
Of course you aren't doomed as you know. I will say that based on data I've collected from real teams, though, that a team that does not estimate its tasks in hours will be less likely to finish the selected user stories for the sprint. (That shouldn't be surprising as it's a rather obvious conclusion.)

You must not have read much of my writing about agile as I've been saying exactly this same thing since 2004 in the User Stories Applied book and publicly in conferences since 2001.
10/2/2014 12:13:38 PM

Pedro Gustavo Torres
So if my teams doesn't waste time in breaking USs into tasks... are we doomed?
Now seriously... I really dislike hours in any software development context.
I'm a bit disappointed with you Mike! Never thoughts to read this from you.
I hope that you recover soon and come back with some good agile stuff.
10/2/2014 11:27:16 AM

Bob Schatz
Great article Mike. Glad to hear you've gone away from Ideal Days. I've always contended the that is a term that just frustrates execs and stakeholders. As soon as they hear "days", the word "ideal" disappears. Another benefit of planning sprints in hours is to teach a team how to manage themselves. By looking at their capacity against the number of hours planned, and then watching it every day in the daily scrum, they avoid overloading.
10/2/2014 7:52:19 AM

Mike Cohn
Thanks, Koti. I liked ideal days for awhile, but I suggest you look at this post on the main benefit of story points:

It will explain the underlying problem with ideal days.
10/1/2014 9:48:26 PM

Mike Cohn
Thanks, Saravana. I'm glad you liked this.
10/1/2014 9:46:48 PM

Koti Reddy Bhavanam
Thank you for this article Mike. THis is one of the reason i prefer the Ideal Development Days for estimation and planning than the story points. While i honor the story points, prefer the IDDs
10/1/2014 7:53:36 PM

Saravana Bharathi
WOW!! Short and an eye opener article.

I liked the way you put it in a simple way. Many times the leadership / Product owners get it wrong. I hear POs say, pick 25 points worth of stories, thats is what your average velocity. What they don't realise is it might take the team more or less time based on many factors.

Once again - Great article Mike.
10/1/2014 11:19:08 AM

Mike Cohn
Thanks, Jai. I'm glad you liked this post.

I spend a lot of time explaining to management (and to teams, product owners and ScrumMasters) that velocity is *not* a good short term predictor. A team may be higher or lower than its average velocity in any given sprint and that won't mean a thing. My experience is that even a good team will have velocity that bounces around about plus or minus 20% of their average. (That is, relative standard deviation of 20%.) For example, a team with an average of 20 may get 16 or 24 in a sprint and have that just be normal variation.

You're right, too, about the dangers of using velocity to drive team performance. Management groups that do that take an extremely useful metric and ruin it by making it one more thing to beat up a team with.
9/28/2014 9:33:06 PM

Mike Cohn
Hi Deepak--

Yes, management often wants an estimate well before one can be adequately provided. I'm OK with that as long as the person requesting the estimate is OK with a wide range in the estimate such as "we'll be done in 6-10 months" or "in the 3 months you're giving us, we'll deliver between 150 and 250 story points." That may be the best the team can do if they do not have any experience estimating their work and do not have any historical velocity data from working together.

The topic of forecasting velocity is fully covered in my "Agile Estimating and Planning" book. It can be done and can be accurate, but it will not be particularly precise (i.e., it won't have a tight range) until the team becomes experienced working together.
9/28/2014 9:29:28 PM

Jai Singhal
Great post Mike!

Often, leadership looks at the team to meet the velocity attained in a successful sprint. Such a practice is not favorable too. Rather in practice, average velocity with a range is better or using man-hours.
I also have the teams look at the total sum of hours from tasks identified during sprint planning to assess if it meets the team capacity using Team Calendar and Sprint length.
Story points provide velocity to assess schedule estimates. When it is used to drive the team performance, the team cannot be self-organizing to maintain the sustainable pace. Thus, average velocity for past sprints is better.

In addition, normalizing story points also help based on PDCA cycle and building a rough estimate to use on large projects and programs with multiple teams. That would be the next progressive step for estimation and planning.
9/28/2014 7:19:03 AM

Deepak Joshi
Hi Mike, this helps and provides clarity on the estimations, especially when the top management is more concerned to know the estimates in hours.

I would like more to know on one important point which is mostly faced by the teams where the organization is still evolving as an agile implementer and teams are immature and top of these, the stakeholders are impatient to know the estimates (for funding budget purpose) and Expected time of completion of the development. At this time even when the stakeholders are apprised with the vision of agile development and they get agree with the approach of incremental-iterative deliveries, still they demand for the estimates. Do you agree that a ballpark estimate can be provided? At this phase do we go for an estimate on epics, may be in terms of story points and then converting the total in man-hours? Small organization do not want to lose the clients and also aspire to adopt the agility. Please advice.
9/28/2014 3:29:04 AM

To leave a comment, please login with your credentials.


Newsletter Sign-Up