A common source of confusion on agile teams occurs when the sprint (“iteration”) backlog and the product backlog are both estimated in hours. To avoid this confusion I strongly recommend estimating these backlogs in different units. In sprint planning the team should always talk of tasks and hours. Sprint planning covers the horizon of typically two to four weeks out. In release planning the team can choose between “ideal days” and “story points.” Regardless of which they choose, they still do sprint planning in hours. I prefer story points for the product backlog items (typically “user stories” are on the product backlog for me). What this means is that I may have a user story (“As a vacation planner, I can see photos of hotels so that I can choose the right hotel for my vacation.”) that is estimate in points–let's say 5 points. That hangs out on the product backlog (PB) until the product owner prioritizes it such that the team chooses to work on it in a sprint. Once selected it is broken down into tasks and hours:

code the user interface, 6 hours

code new stored procedure, 4 hours

add photo maintenance page, 8 hours

write automated tests, 5 hours

and so on.

So both are used but at different times and when viewing items at different horizons. Here's a key reason I prefer points: If I estimate the PB items in ideal days then it is too easy to mistakenly think that the PBIs and the items on the sprint backlog are estimated in the same unit. After all, the sprint backlog is estimated in ideal hours and the PB is estimated in ideal days. So, they're the same unit (times 8 for the PB), right? This is a huge fallacy. On average the teams I've coached spend 30 minutes breaking a product backlog item into tasks and estimating those tasks.

So, let's not call that estimate “hours”. Let's call it “hours I thought a lot about.” On the other hand, teams I coach spend 2-3 minutes on average estimating the PBIs. (These items don't need the detailed thought upfront; we just want a rough estimate so we can decide priorities and basic schedule.) So, let's call these “hours I pulled out of the air.” When the PB and the SB are estimated in days and hours, it is too tempting to divide the number of days on the PB (times eight) by the number of hours finished per sprint and think that's an estimate of how long the rest of the project will take. However, that's bad math. It's literally dividing apples by oranges. It's “hours I pulled out of the air” divided by “hours I thought a lot about.” The result will be meaningless. The problem goes away when teams go to two-level planning (release and sprint) and when they track velocity in story points.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

So I could maintain my Product Backlog Items in User Stories.. until I am prepared to move them to a development sprint. In this way, I can prioritize items in the backlog in an easier to create common demoninator. Because we assign hours to tasks (which roll up to the Stories).. I would then inherit some notional ideas about an hrs to story point ratio over time. Am I making sense?

Posted by Stephen on 2013-11-05 13:58:12

Hi Peterman--Absolutely--I like to release every sprint as well. Actually, I like it when I work with teams that release daily (or even more often). I have historically used "release planning" to mean any sort of multiple sprint plan. You might want to see this post about finding a different term than "release planning": http://www.mountaingoatsoftwar...

Posted by Mike Cohn on 2013-03-14 14:31:42

Remarkable. But keep in mind that not all agile projects use release planning. In my opinion I prefer release functionality for customer use with every sprint.

Posted by peterman ager on 2013-03-14 10:43:30

Hi Shanthi--
In the situation you describe, I'd advise having a small group of team members estimate the size of the story. Pick a few people and have them estimate all things for the next month. After a month rotate 1/3 or 1/2 of them off and another group on to estimate, etc. Be sure to establish a common baseline for what a story point means.Posted by Mike Cohn on 2012-01-09 18:54:11

Thanks Mike. I really appreciate your quick response.
Typically when business requests a new feature we create a PBI. Most of the time we do not know which one of the multiple teams (all teams have same size and skillsets) will really be working on that item. So from practical perspective do you recommend one of the technical directors/managers make the call on what team needs to be assigned for that PBI and then involve that team in the PBI estimation?Posted by Shanthi Dev on 2012-01-08 21:33:51

Hi Shanthi-
The entire team should be involved in that early estimate. We've known for years (and it's logical anyway) that the best estimates are given by those who will do the work. Getting the actual team involved in those early estimates will likely lead to better discussion about the product backlog items which will reduce the number of user stories found right before the sprint starts.Posted by Mike Cohn on 2012-01-08 19:03:46

It has worked really well for us when we estimate tasks that make up the user story in hours and compare it to the team capacity before teams make a commitment for the user stories in the upcoming iteration. We do this in the sprint planning phase 2.
But my confusion is about timing of the estimates for user stories (in story points) within product backlog. Let me clarify this a bit. Our Product backlog items are at a high level (sometimes at an epic level) that make sense to Business, Customers and Stake holders. The PBIs (epics and user stories) are estimated weeks to months ahead of iteration start by the team leads, a few team representatives and technical managers. But what typically happens in days leading to the iteration start and during sprint planning phase 1 is that the team invariably discovers new stories that either breakdown the epic into smaller stories or compliment the existing story or add constraints (non functional requirements). Everybody is in consensus that these new stories have to be added and prioritized by PO for the original featured user story to be releasable. Since these stories have just come up and we are close to starting the iteration the entire team still estimates them in story points for the PO to prioritize. So now we have done 2 levels of estimation (user stories in story points for sprint planning phase 1 and task in hours for sprint planning phase 2) even though we are in the proximity of the iteration kickoff. I dont have a problem with this but I always wondered if there are guidelines as to how to mitigate the addition of new stories right before iteration begins. On the same subject I also would like to know if there are guidelines as to whether entire team should be involved in product backlog estimation or just a few representatives like we do today should suffice? My concern is about teams being able to participate in PBI estimation fully if they are already in the middle of current iterations.Posted by Shanthi Dev on 2012-01-08 08:55:26

Would you be able to switch off trackbacks? They are really just noise, and generally make an otherwise interesting comments section very difficult to follow.Posted by Steve H on 2010-03-30 02:34:08

Hi Patrick--
This was a big enough new topic that I've blogged about it separately at http://blog.mountaingoatsoftware.com/?p=66Posted by Mike Cohn on 2008-11-25 03:13:49

Hi Mike,
To start with, excellent book. I've gone through it several times and marked it up in all kinds of ways with notes.
I'm curious about something. Isn't it possible to do away with sprint planning in hours altogether and just commit to story delivery? If I'm understanding correctly (and I may not be), what matters are completed units of business value. In that case, a burndown would seem to only offer a false sense of progress for management whereas a burnup (which indicates stories completed (again, if I follow correctly)) would seem to mean more. Going back to your good point that your hours are not my hours, and based on the fact that we'll have a velocity calculation that will tell us about how much work we can complete in a given sprint, I'm not seeing the benefits of the hours breakdown. Could you clarify for me please? Thanks.Posted by Patrick on 2008-11-22 11:59:48

Hours is too much fine grained. Use timeboxes such as half days.Posted by Michael Decascos on 2008-08-06 22:06:01

Hours is too much fine grained. Use timeboxes such as half days.

Posted by Michael Decascos on 2008-08-06 22:06:01

Hi Prabhakar--
Yes, all three of the estimate types you list are needed. And yes, these may not be all the same group. I would, however, like the groups doing sprint planning (and estimating in hours) and the group doing product backlog / release planning (in story points) to be the same group. I find that Planning Poker works well for the story point sizing and use it for that. I don't personally advocate Planning Poker for estimating in hours during sprint planning but others have had success with it during that meeting.
For assessing value I usually have the product owner convene a group whose opinions she respects. I then have them estimate in "Priority Poker" which is essentially the same as Planning Poker but uses Ace - 9 in a regular deck of cards. We assess relative value from 1-9 using those cards and following the same rules of Planning Poker.Posted by Mike Cohn on 2008-05-13 15:32:43

Hi Prabhakar--

Yes, all three of the estimate types you list are needed. And yes, these may not be all the same group. I would, however, like the groups doing sprint planning (and estimating in hours) and the group doing product backlog / release planning (in story points) to be the same group. I find that Planning Poker works well for the story point sizing and use it for that. I don't personally advocate Planning Poker for estimating in hours during sprint planning but others have had success with it during that meeting.

For assessing value I usually have the product owner convene a group whose opinions she respects. I then have them estimate in "Priority Poker" which is essentially the same as Planning Poker but uses Ace - 9 in a regular deck of cards. We assess relative value from 1-9 using those cards and following the same rules of Planning Poker.

Posted by Mike Cohn on 2008-05-13 15:32:43

I have felt the need for three kinds of estimations.
1) For the tasks in a sprint, effort estamation in hours helps to keep track of progress and work out the velocity
2) For release planning, size estimation is more meaningful because enough details are not available for effort estimation
3) For prioritization of tasks in a product backlog, value estimation is most useful or rather value per size unit.
Can planning poker with different set of participants help? For example, a group of predominantly business level persons are likely to suggest story points in terms of business value. A group of architects and designers would be more focused on size. While a group consisting predominantly of developers and testers would think in terms of efforts.Posted by Prabhakar Karve on 2008-05-13 09:09:44

Hi Dan--Hopefully I can explain this better with this follow up comment than I did in the initial post then. First, let's establish that establishing the sprint backlog tasks in hours is a good thing. I think it is. After all, we are about to start the work and the work will all be completed typically within 2-4 weeks (a sprint). If we're about to start it we should understand it in enough detail that we can put a reasonable guess of the hours on each task. When I coach teams I put a lot of emphasis on making sure they know that an estimate on the sprint backlog may go up. If we discover something is harder than initially expected that is exactly what should happen.
Another reason that I like hours on the sprint backlog is that I don't like points (or abstract units) on the sprint backlog. That's a backhanded recommendation but let me clarify. I don't like abstract units on the sprint backlog because it leads to thinking like "I'm 70% done and it was initially a 10-point thing so I must have 3 points left." We are BAD at estimating percentages so I don't want to use a sprint backlog estimating process that encourages estimating in percentage complete. I'd far rather have team members essentially re-estimate ("how many more hours will this take?") rather than ask "what percentage done am I so I can put a new abstract unit on?"
So, if I like hours on the sprint backlog, why not use hours on the product backlog? A couple of reasons:
1) if we use hours on the sprint backlog *and* the product backlog, people will make the comparisons I warned about in the blog posting itself. They will add up the hours of remaining product backlog items and divide it by the number of hours finished last sprint and expect that to mean something. It won't--it's dividing apples by oranges and is meaningless. Although we call both "hours" they aren't really the same unit since a lot of work goes into the hours estimates of the sprint backlog but not a lot goes into the hours estimates of the product backlog items.
2) Studies have shown we're better at relative estimating ("This building is twice as tall as that building.") than we are at absolute estimating ("This building is 700 feet high."). I think that's a compelling advantage for the product backlog items. It's an advantage of course for estimating sprint backlog items in hours but I don't do that because the sprint tasks are small enough and occurring soon enough that we should be able to do hours. If we like relative estimating (and we should) then story points are the right way to do it for the product backlog.
3) Time estimates are not additive. The amount of time you take on something is estimated in "Dan Hours" and my work is estimated in "Mike Hours." We can't add those because they aren't in the same unit. That's not a problem when we work with tasks (it's likely we know which sprint backlog items you'll do and which I'll do). It would be a problem for product backlog items (which are likely worked on by multiple people) if they were estimated in hours.
There are a handful of other reasons that you'll find in the Agile Estimating and Planning book but the main arguments are the ones I just made.
Regards,
MikePosted by Mike Cohn on 2007-07-24 20:08:59

Hi Dan--Hopefully I can explain this better with this follow up comment than I did in the initial post then. First, let's establish that establishing the sprint backlog tasks in hours is a good thing. I think it is. After all, we are about to start the work and the work will all be completed typically within 2-4 weeks (a sprint). If we're about to start it we should understand it in enough detail that we can put a reasonable guess of the hours on each task. When I coach teams I put a lot of emphasis on making sure they know that an estimate on the sprint backlog may go up. If we discover something is harder than initially expected that is exactly what should happen.

Another reason that I like hours on the sprint backlog is that I don't like points (or abstract units) on the sprint backlog. That's a backhanded recommendation but let me clarify. I don't like abstract units on the sprint backlog because it leads to thinking like "I'm 70% done and it was initially a 10-point thing so I must have 3 points left." We are BAD at estimating percentages so I don't want to use a sprint backlog estimating process that encourages estimating in percentage complete. I'd far rather have team members essentially re-estimate ("how many more hours will this take?") rather than ask "what percentage done am I so I can put a new abstract unit on?"

So, if I like hours on the sprint backlog, why not use hours on the product backlog? A couple of reasons:1) if we use hours on the sprint backlog *and* the product backlog, people will make the comparisons I warned about in the blog posting itself. They will add up the hours of remaining product backlog items and divide it by the number of hours finished last sprint and expect that to mean something. It won't--it's dividing apples by oranges and is meaningless. Although we call both "hours" they aren't really the same unit since a lot of work goes into the hours estimates of the sprint backlog but not a lot goes into the hours estimates of the product backlog items.2) Studies have shown we're better at relative estimating ("This building is twice as tall as that building.") than we are at absolute estimating ("This building is 700 feet high."). I think that's a compelling advantage for the product backlog items. It's an advantage of course for estimating sprint backlog items in hours but I don't do that because the sprint tasks are small enough and occurring soon enough that we should be able to do hours. If we like relative estimating (and we should) then story points are the right way to do it for the product backlog.3) Time estimates are not additive. The amount of time you take on something is estimated in "Dan Hours" and my work is estimated in "Mike Hours." We can't add those because they aren't in the same unit. That's not a problem when we work with tasks (it's likely we know which sprint backlog items you'll do and which I'll do). It would be a problem for product backlog items (which are likely worked on by multiple people) if they were estimated in hours.

There are a handful of other reasons that you'll find in the Agile Estimating and Planning book but the main arguments are the ones I just made.Regards,Mike

Posted by Mike Cohn on 2007-07-24 20:08:59

I've been reading your book and ran across this very point and it just doesn't make any sense to me. On the one hand you make the argument that story points are superior for a variety of reasons and on the other you say to plan sprints in hours. This invalidates many of the valuable points you make in regards to the benefits of story points, namely that it changes the discussion from time to size and prevents people from mistaking ideal days for literal days, etc. I do understand that the averages don't balance out as well with story points on such a short cycle, but I just don't see how introducing a new method of estimation and a new dialog helps matters. Aside from the fact that points don't average out as well over shorter time boxes, what are the other reasons for switching from points to hours at the sprint level after using points at the backlog level? It honestly seems like a concession made to those who aren't comfortable with a more free form style of estimation and project management. And how do the hours tie back to the story points completed in a given sprint? If they don't, what good are they? See? Told you I was confused. ;)Posted by Dan R. on 2007-07-24 03:11:08

I've been reading your book and ran across this very point and it just doesn't make any sense to me. On the one hand you make the argument that story points are superior for a variety of reasons and on the other you say to plan sprints in hours. This invalidates many of the valuable points you make in regards to the benefits of story points, namely that it changes the discussion from time to size and prevents people from mistaking ideal days for literal days, etc. I do understand that the averages don't balance out as well with story points on such a short cycle, but I just don't see how introducing a new method of estimation and a new dialog helps matters. Aside from the fact that points don't average out as well over shorter time boxes, what are the other reasons for switching from points to hours at the sprint level after using points at the backlog level? It honestly seems like a concession made to those who aren't comfortable with a more free form style of estimation and project management. And how do the hours tie back to the story points completed in a given sprint? If they don't, what good are they? See? Told you I was confused. ;)

Posted by Dan R. on 2007-07-24 03:11:08

I agree with your assessment here. I've always found points to be a much more useful technique. It really forces everyone to stay focused on the relative size of items instead of thinking about everything in terms of duration.Posted by Tod on 2007-01-14 15:55:50

I agree with your assessment here. I've always found points to be a much more useful technique. It really forces everyone to stay focused on the relative size of items instead of thinking about everything in terms of duration.