Do you remember that movie “The Hours” with Meryl Streep? Me, neither.
Last week, I was talking with some colleagues on LinkedIn about the utility of estimating tasks in hours. For those of you with a Scrum background, you know it’s kind of tradition to estimate user stories in story points (or something like them), but then you break them into tasks. The tasks are estimated in hours, and the total of all those hours forms the basis of your burndown chart.
I’m not saying my experience should govern everyone else’s, but I haven’t estimated tasks in hours in a very long time.
First of all, the whole thing begins with the premise that we can accurately estimate our tasks in hours, and this tends not to be the case. There’s a common misconception that, if you are trying to estimate a smaller activity, that your estimates will be better. This is not true. It is true that the actual hard units of deviation will be smaller (being off by 2 hours is a smaller hard time span than 2 weeks), but there’s no reason to believe your estimate will be better just because the scope is smaller. You might say at this point, “Well, ok, but it’s not really going to affect the project that much if I think it’ll take 2 hours to set up some database tables, and it takes 3.” That’s a 50% deviation, but ok, sure, that extra hour may not affect much in the grand scheme of things. But what if you’re off by an hour for all your tasks?
That’s being generous. What is pretty common is to have a task that you think will take 4 hours, and it ends up taking 20. You take these extremely common incidents of being wrong and you put them together, and you can easily end up with days or even weeks of error per sprint. The absolute units of time give the appearance of precision, but it’s a false appearance – perhaps all the more dangerous for its compelling nature.
Because the units of time are small, this seems like a small problem, but that’s only because you’re thinking of one task. When you look at the cumulative effect of this problem, it’s actually pretty serious. It sets unrealistic expectations. Your burndown chart whose entire raison d’être is to visually represent sprint progress is like a clock that loses 5 minutes every hour – it doesn’t take long before that clock is worse than worthless, because it’s misleading. Have you ever had a burdown chart stay level or go up during a sprint? More often than you’d like, right? Maybe that’s a signal that your workflow isn’t being managed well, but those same things can just as easily happen for no reason whatsoever, just because your hours remaining started wrong and are correcting themselves. This isn’t even taking into account the fact that, when people see hours, they expect those mini-deadlines to be hit. Patience for spending 20 hours on a task wears pretty thin when you’ve told everyone it would take 4, initially.
This leads me to my next point – estimating in hours takes a long time to do. All that time spent on being wrong could have been spent coding, getting acceptance criteria, or anything that would have moved toward delivery. Hell, even using that time to make the world’s longest paper clip chain would have been at least as profitable. Note, I’m not saying it’s a waste of time to break stories into tasks. That process helps you understand what’s expected of you, ferrets out oversights, and helps in swarming. But what are you getting by putting hours on those tasks?
“Well, the hours can help us verify if our sprint commitments are reasonable.”
Can they? First of all, even the Scrum Guide doesn’t use sprint commitments, anymore, but let’s pretend that’s still a good idea. If you can make some kind of equation between story points and hours, then why not just skip the whole story point process? Just break everything into tasks, get your hours, and base your planning on that?
“Well, relative measurements and velocity are more accurate planning tools than hourly estimates.”
Exactly. So how are those hours helping you, again? You are using the less accurate tool to critique the more accurate tool? Is there anything at all those estimated task hours help you do that relative measurements or empirical metrics can’t?
If you’re a Scrum sort, try an experiment next sprint just to see what happens. Break your stories into tasks, but don’t put hours on them. If you want to burn down, burn down story points (or whatever you use). Just try it. See if your workflow or end result is meaningfully impacted. See if you miss them. You might find that you’ve made a significant improvement in your practice.