Why We Dropped Ideal Hours
Since converting to Scrum, my team has been in the practice of planning our capacity for a sprint in terms of ideal hours. We had a fairly simple spreadsheet where we’d enter the number of vacation days each team member was planning and taking and their estimated “overhead” percentage (all of the time spent in meetings, handling random things that come up, etc.). During our Sprint Planning meetings, we would then estimate all of the tasks for the stories in terms of ideal hours – how long we expected that task to take assuming zero distractions and interruptions. We then took on as many stories as we had enough ideal hours for.
Over time, I became less and less satisfied with this way of planning capacity. In general, it didn’t seem to add much value to the process and increased the length of the planning meeting. Additionally, because we track the progress of a sprint using the number of hours of work remaining, the team had to continuously update both our task board and our online tool (whether Rally, ScrumWorks, etc.) or others wouldn’t have a good sense of how the sprint was going.
At best, this represented time (albeit, not a ton, but still enough that it hurt) not spent doing actual work. At worst, it was a complete waste since there were usually caveats associated with the hours as they are presented on the board or in the tool, e.g., “well we’re way over in terms of hours we spent on this task, but we realized that all the work we did will save us time on the next 5 tasks so it’s basically a wash” or “we’re going to leave this task at 6, but we might lower it to 1 shortly depending on how something turns out”.
One could respond that those types of things can and should be tracked in a tool and the problem is not that we were using ideal hours, it was that we were being lax in updating the tool and, by extension, the rest of the team and stakeholders. While this was initially my thought, I came to disagree for the following reasons:
- It seemed odd that we were estimating work in terms of a fictional unit – the ideal hour. Since there is very rarely an extended period of time during which someone really doesn’t have any distractions and is free to focus on a single task, I don’t understand why we ask them to imagine how long a task would take under those conditions. Granted, it makes the math easier, but that doesn’t make the estimate any better and might actually make it worse.
- We limited the granularity of ideal hours to whole hours. Even if ideal hours were a real unit, limiting their granularity means limiting their accuracy and usefulness. Granted, estimating in whole hour blocks is faster and easier, but the very mechanism that makes it such also severely limits its usefulness – especially when there is disagreement within the team about how long something is going to take and we just settle with the average.
- In my experience, estimating in ideal hours didn’t help us. There were times when we had to go to the Product Owner and say that we couldn’t get all of the stories that were tentatively put on the sprint backlog done in time (because the number of ideal hours needed was higher than our capacity) – but those were identically the times when the number of story points on the sprint backlog exceeded our velocity and/or where we had huge 8 point stories which we all later agreed should have been multiple stories whose points would have added up to more than 8.
For a while, I didn’t have a good suggestion as to how to do away with ideal hours. Then I saw this presentation on the ScrumAlliance website. I’m going to take the liberty of paraphrasing the author: if we’re really doing our story point estimates well, and we’re always trying to break things into smaller stories so that story sizes are as uniform as possible, and we’ve got some historical data to tell us what our velocity is, why don’t we just use that to figure out how much to put into a sprint and save ourselves the trouble of estimating tasks?
Under such a scheme, we would still task things out so that we could uncover any gotchas and get a general consensus in the team as to what needs to be done. We just wouldn’t estimate hours for tasks and then track progress in terms of hours remaining. Granted, it might turn out that we sign up for an amount of work that causes us to either end early, have to work a little extra, or miss a story, but we run that risk with ideal hours too – we just spend more time doing it.
In terms of tracking the progress of a sprint, the author suggests having a burndown of tasks rather than hours – which is obviously less quantifiable but perhaps no less valuable. Our current burndown uses hours, but it really just gives the illusion that we know exactly how many hours are remaining. Not having an ideal hour burndown just means we don’t have that illusion anymore. As the author points out, precision doesn’t equal accuracy and accuracy is what we’re really after.
Lastly, there was the issue of how to adjust the amount of work we pull into a sprint when we know that someone will be on vacation. Ideal hours gives us a nice way to do this because we just subtract the appropriate number of hours from our capacity. That really isn’t that accurate, though, because any given day in a two week period might be very different than any other day in terms of how much someone is able to focus on direct work. Treating all days as identical in terms of capacity is again mathematically easier but perhaps no more accurate. We could probably do just as well by “manually” adjusting the velocity down a few story points based on gut feelings. Again, precision doesn’t equal accuracy.
When I presented these ideas to the team, we all decided that it was worth trying – after all, even if we crash and burn, we’ve only lost two weeks. That was 2 sprints ago and we all seem pretty happy not using ideal hours. Our task board is just the same except we don’t put hours on our tasks. Our online tool is the same – we just assign every task 1 estimated hour. Our burndown chart thus shows the burndown of tasks. During planning, we are extra conscious of task breakdowns and try to make all tasks as uniform a size as reasonably possible.
All in all, I’m very happy we’ve moved away from ideal hours and are relying more on our velocity and “gut checks” to know how much work to pull into a sprint. I highly recommend trying it.
Robert Dempsey
November 18th, 2009 at 10:15 pm #
Great post Ken. Thank you for sharing your experience. We’ve been looking at not using ideal hours for tasks anymore either as the overhead of tracking it all can get expensive, and once any management level person sees hours they immediately think set in stone, regardless. The point of ideal hours for tasks (as opposed to story points for stories) is to figure out if we have added more stories to the backlog then we really can do given the current hours the team can put in. Regardless, we all find out what works for us, and if removing ideal hours is working for you all and you can see the amount of working getting done, that’s what counts.
Ken Furlong
November 19th, 2009 at 7:42 pm #
Thanks for the comment, Robert. You’re absolutely right about task hours being intended for helping to know how much work put into a sprint, that was exactly what we were using them for. We just found that we could decide how much work to put in a sprint just as well using our velocity and a quick gut check from everyone on the team. The ideal hours didn’t actually help us at all – each team is different, of course, and I can easily imagine scenarios where tasking out stories using ideal hours or some other time measurement helps a great deal.
In any event, please let me know how it goes if you do decide to experiment with dropping ideal hours.
Emily
June 1st, 2010 at 12:09 am #
Great post Ken. Thank you for sharing your experience. We’ve been looking at not using ideal hours for tasks anymore either as the overhead of tracking it all can get expensive, and once any management level person sees hours they immediately think set in stone, regardless. The point of ideal hours for tasks (as opposed to story points for stories) is to figure out if we have added more stories to the backlog then we really can do given the current hours the team can put in. Regardless, we all find out what works for us, and if removing ideal hours is working for you all and you can see the amount of working getting done, that’s what counts.