What’s the deal with story points and agile estimation techniques, and why can’t we just improve our estimates over time? That’s part of the question that a friend of mine asked recently, and I’m going to respond to it in this blog post.
My friend is relatively new to agile and so he has been asking lots of excellent and probing questions. Here is an email he sent me:
Agile practitioners estimate work in terms of points and then after each sprint determine their velocity so that they can make better estimates about how much work remains in terms of real time. Is there a better way to do this? I propose that we estimate the amount of work remaining in real man-hours. Then, after each sprint, we estimate our reality_factor as (reality_factor = estimated_hours / actual_hours_taken). The goal being that the reality_factor should converge to 1 as we get better at estimating time that it takes to do things.Benefits:
- If anyone asks how much work is left, you don’t have to do a calculation using the velocity to get to real man-hours.
- As you converge, the meaning of real man-hours is universal. With points, you have to re-converge to the meaning of 1 point whenever you start a new project or work with a new group.
Drawbacks:
- You have to keep careful track of time.
What do you think?
Man-hours is also a deceptively simple metric, because it implies that adding more people (ie, more man-hours) to a project will speed it up. And so managers are often tempted to add more people to a project late in the process in order to speed up delivery, but this rarely has the positive effect desired. In fact, it may slow the team down further.
So keeping velocity separate from a metric like man-hours is an intentional obfuscation. It also addresses a very important issue in estimation. Generally speaking, we are not very good at estimating things in absolutes. When we try to estimate in absolutes (ie, a concrete number like 2 days), we tend to give our most optimistic estimate, and often it’s a gut reaction. There are so many uncertainties in software development that it’s very hard to estimate in absolute terms.
Fortunately, most people are much better at estimating in relative terms. We still won’t be perfect, but it’s much easier to say that “Task B is twice as hard as Task A”. This sort of relative estimate is much more likely to be accurate than saying “Task B will take 10 hours and Task A will take 5 hours.”
If we plan based on these relative estimates, we are much more likely to be accurate in our sizing of how hard a task is. And if we stay consistent in that relative sizing across estimates, then we can look at our historical velocity. Historical velocity is an absolute number, but’s that okay. We can say definitively that the team accomplished 25 points of work in the last iteration. And so that is a number grounded in reality, and so it provides a frame of reference for the relative estimates of story points.
So, would a “reality factor” help in estimation? I argue that it would not, because the formula that my friend proposes above is still based on an absolute metric of hours that we simply aren’t good at estimating in. Historical velocity serves the same purpose that my friend is trying to account for with a reality factor, and yet it still lets us stay in the world of relative estimation, which is a world we are much more likely to succeed in.
