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.

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

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

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.

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.

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

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.

Hi Patrick—

This was a big enough new topic that I’ve blogged about it separately at http://blog.mountaingoatsoftware.com/?p=66

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.

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.

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.

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?

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.