In my guest post on Mike Dexter’s blog, I briefly touch on estimating in hours.

Estimating in hours during sprint planning is something that’s been around for a long time. Robert Martin notes this in his popular and influential book Agile Principles, Patterns, and Practice’s:

Many developers find it helpful to use “perfect programming hours” as their task points.

This is the process that I have followed for the last two years; estimating in story points before the iteration planning and then estimating each task in hours at the iteration planning, subtracting the hours off the available hours that he team has for the sprint. There are a number of disadvantages with this approach:

– On average, a typical employee needs to take off about a dozen days leave on an unplanned basis. This might be due to sickness or some family issue etc. In this situation the team finds it has fewer available hours than planned. So even if all the estimates were exactly right, the team cannot do all tasks and stories in the iteration unless staff do enough overtime to make up the shortfall from the unplanned leave.

– Those 2 years have taught me there are three simple rules to iteration planning (known as sprint planning in scrum):

1. If your estimates were within 20% of your actuals, you are doing alright
2. If your estimates were within 10% of your actuals, you are doing great
3. If your estimates were exactly bang on, you just lucked out

I am talking about the overall estimates here, so if your team only gets 80% of the work that you had originally planned done by the end of the iteration, as long as the work you’ve done is of a good quality, you are probably doing OK. Your individual task estimates are likely to mostly be much more than 20% out, and the law of averages will mean your overall estimate for work done in the iteration will be a lot closer than your individual estimates.

– Different members of your team will takes different amounts of time to complete the same task. Fred might be the expert and be able to do it in 3 hours, whereas George might not have any similar experience and need 30 or 40 hours if left on his own. But this doesn’t necessarily mean Fred should do the work. It may be more important that George gets the training he needs. After all, if Fred has to take unplanned leave, the team is stuck if no one else know how to do the work. Maybe with just a couple of hours of Fred’s help, George can do it in 3 or 4 hours? So do you estimate 3 hours for Fred on his own, or 5-6 hours for Fred and George to work together on it? This needs to be decided at the planning meeting.

– Making too many upfront decisions will always result in some of those having to be reversed over the course of the iteration. Being less precise at the sprint planning gives the team more wriggle room. For example while it is okay to plan that Fred helps George with one task at the iteration planning, you wouldn’t want to do this for every task. The reality is every task is the teams responsibility and the developer who picks up any task will often be different to what anyone might think at the time of the iteration planning.

– Estimating every task in an iteration takes a long time, and the business users don’t care about your estimates at that level of detail. All they want to know is “will it be done by the end of the iteration?”

I have recently tried an alternative and simpler way of doing estimates. We just use the story points estimates that we gave before the iteration planning meeting and use the planning meeting to discuss the tasks that we will do for each story. Without the detailed estimates, the meeting has reduced from 2 hours down to just half an hour. The business users also find it much easier and they are allowed to get back to work sooner as are us developers.

This changes the iteration burn down chart. Instead of reducing in hours each day, the y axis is story points. So for a couple of days it may show a horizontal line and then when the first story is complete the line will drop by the number of story points that was estimated for the completed story.

I will update you with more information as I get more experience with this approach. In the meantime please use the comments or contact me on twitter if you have any questions. Also check out Jeff Sutherland’s posts below.

Additional reading

http://mdexterscms.wordpress.com/2014/03/03/guest-post-10-top-tips-for-better-agile/
http://scrum.jeffsutherland.com/2007/03/time-tracking-is-anti-scrum-what-do-you.html
http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html