How to Estimate Work
A common question
How long is it going to take us to build a certain solution capability? How much effort is it going to take? These are some very common questions you can hear in almost every organization.
Let’s talk about how to effectively answer this. These are not simple questions at all, there’s a lot more to it than may seem at first.
What are estimates really used for?
First and probably most important thing about estimations of work is actually not even how you estimate but rather how is that estimate actually used. Estimates can be used to make solution development a more productive task or a nightmare – all depending on how we use those estimates. So, what’s a good usage? We have to remember that estimates are—just as the name suggests—an approximation. We can never be really accurate with estimations. The reason for that is the complexity of the solution that is being developed. And despite the fact that there are plenty of ways to convince ourselves that we can foresee the future, some important facts will only reveal themselves as we progress with the actual work. That means that the larger the chunk of work that we are estimating, the more inaccurate we’re going to be with our estimations. So, it’s just an approximation and it should be treated like one. The bad scenario is when it’s treated as an exact figure that the teams are then held accountable to. When that happens and some estimates work out and some, of course, don’t, if the teams are pressured, they adjust their behavior: they will estimate defensively next time and whenever they see that they are not meeting their estimations they will try to meet them no matter what, even if at the cost of cutting corners. So, this is an important message to leaders at all levels: the way YOU treat estimates to large extent determines teams’ behavior and ultimately the productivity of solution development.
How to estimate?
Second, the estimation itself. Here we also have good and bad scenarios. It matters a lot who performs the estimation. It is always best if the knowledge workers that do the work, also estimate it. If I’m working with this codebase, I’m the best positioned to tell you how long it will take to add this new feature. Not only does this provide higher accuracy of estimations but also increases the sense of ownership and commitment on the part of knowledge workers.
But additionally, the big question is what is it that we are estimating; what kind of work items are those? See, if we took a larger initiative and split it by expertise or by components of the system—which is what organizations often do—then the estimates will be very inaccurate. But if, instead, we sliced that initiative into chunks of customer value, the estimates would be much more reliable. Even if not so accurate at first, starting to work on such an item would allow us to make corrections to those estimates simply because a lot of complexity lives across different layers of the system, and such an approach reveals it quickly. And, of course, it’s best if the entire team is involved in estimation, and maybe some other subject-matter experts, too, to help. But teams are the primary estimators of their own work.
Lastly, comparative estimation can be very useful because it allows to utilize empirical data on the work the team has already completed in order to estimate the upcoming work. So, basically, how they do this is they say: If this is a new work item, how does it compare to the ones we’ve recently delivered? If it feels like 1.5 times bigger than the one they delivered in the last iteration, then that’s the estimate. And to make it numerically easier, they may assign some unitless value to it. So, the size of the previous item is two and the new one is three. And they use the same unitless “currency” further and further.
How is estimation of work done in your organization? Think of one specific step that would improve that process.