In his recent article, “The NoEstimates Movement”, Ron Jeffries asked for concrete ways to help wean organizations off estimates. I have one to share.

I have spoken about this but not really written it down, so let me do that here.

In the early days of XP, I remember reading in Planning Extreme Programming that “I don’t have enough time” feels like an impossible problem to solve, but “I have too much to do” can open us up to more realistic options. Creating time lies beyond most of our abilities, but doing less always remains an option.1 In a similar vein, I recommend treating estimates as budgets, so instead of saying, “This task will take 2–3 days”, try saying, “We can afford/justify spending 2–3 days on this task.”

I believe that this little language trick helps in three ways, all at the same time.

Parkinson’s Law

Parkinson’s Law states that we will overstate the significance of any task, and as a result will make sure that it takes every bit as long as we thought it would take. If we express our situation as an estimate, then when the task takes too long, we can shrug it off as “we got that wrong”. If we instead express our situation as a budget, then we can feel a subtle compulsion not to go over budget. “We don’t know how long it will take” can leave us feeling helpless; “we need something in 2–3 days” can open us up to options. This leads to the next point.

Not Only Tasks, But Also Outcomes

When we put a task on our plan, we risk losing sight of the goal or outcome of completing that task. If we estimate 3 days to do it, and later we discover that it might take 2 weeks, this often leads to arguments about whether we should do it, why it will take so long, why we can’t estimate accurately… the typical reasons that have caused me to gravitate towards a #NoEstimates approach. When I interpret “3 days” as a budget, then later realise that I can’t finish the task in 3 days, I feel more open to considering what I can finish in 3 days. This leads me to one of the most Powerful Questions I ever learned: “What else could I give you with the resources we have available?” Instead of feeling trapped in arguing about the original agreement and whether I broke it or you broke it, this question helps me get past that quickly and on to, “What should we do now? We have 3 days. We can’t get that task done. Why did you need it again? What else could I give you in 3 days that would meet that need?” This feels a lot like the difference between “I don’t have enough time” and “I have too much to do”.

Not Only Cost, But Also Value

In general, we do a poor job of determining the value of software, and often the smaller the task, the less we know the value. When I focus on estimates, I end up focusing on cost, and for a wide variety of reasons I’ve learned over the years to view such focus skeptically. Imagine the situation where we agree on a task and estimate it at 3 days. Now I’ve started working on the task and after about one day of work, I notify you that I’ll need 2 weeks instead of 3 days. When focused on the estimate, you will likely feel an impulse to argue about the estimate. You might do so quite passionately, and this could lead to counterproductive bad feelings—ones that actually slow down the work. With any luck, though, you’ll remember that finishing this task will generate enough extra profit to fund an additional 2 months of work on the project. Now for a very Powerful Question: If you always knew that this task would cost 2 weeks, would you have invested in it anyway? If you would have felt good about the outcome anyway, then don’t let one programmer’s overly-optimistic guess stop you from feeling good about it!

You Can Start Today

Good news, everyone: thinking about estimates as budgets requires nothing more than you changing your mind. You don’t need permission to see estimates as budgets. You don’t even need everyone around you to see estimates as budgets; you can simply start doing it, and use it to try to build new bridges with the stakeholders whom your inaccurate estimates have tended to disappoint. Pay attention to changes in your behavior, as well as the behavior of others. Treat this as a tool for building trust, rather than merely a tool for avoiding responsibility. In the worst case, you’ll merely disappoint your stakeholders less often, because you’ll have found other ways to satisfy their needs from time to time. Even if you get nothing more than that, it only costs you trying to change how you interpret numbers in a spreadsheet. Even if you can’t estimate the resulting value, surely you can afford this tiny up-front cost.

(Do you see what I did there?)

References

Kent Beck, Martin Fowler, Planning Extreme Programming. If you think that Scrum invented Agile project planning, then think again.

Eli Goldratt, The Goal. An introduction to an alternative to cost-focused thinking.

Gerald Weinberg, The Secrets of Consulting. I believe that I learned some of my most powerful questions from Jerry’s books, and I like this one as a place to start learning about them.

Chip and Dan Heath, Switch: How to Change Things When Change Is Hard. The authors identify “script the critical moves” as a powerful tool in promoting difficult change. Letting go of fine-grained task estimates certainly qualifies as “difficult change”, and I imagine you’ll encounter other difficult changes in your career that you might like to lead. This book has given me some good tools to help in that regard.

  1. Even when you believe that you don’t have the option to do less, you almost always do, although you have to weigh it against the consequence of doing less. There are simply some things you can’t do, no matter how much someone else yells at you to do it.↩︎