Posted on December 12, 2016 by: Joe Wilson, Production Director
There has been a “conversation” going on in project management circles for the better part of five years about the practicality of doing estimates and whether we should just stop even trying. I use the quotation marks because it more closely resembles the political shouting match you enjoy with your uncle once a year at Thanksgiving dinner. For real, if you want to see some process nerds typing in all caps and a host of NSFW animated GIFs involving user story estimate points and “The Lord of the Rings” characters, just go out to Twitter and type #NoEstimates into the search bar. It’s a flame war that shows no signs of abating.
The #NoEstimates movement was started around 2011-2012 by a trio of project managers, Vasco Duarte, Neil Killick, and Woody Zuill. They were each individually seeking to solve what they saw as a fundamental problem with software development: an overdependence on estimation. Zuill was technically the first person to use the hashtag when he posted a link to his blog article about the subject on Twitter. Project managers use estimates for everything. We use them to determine budgets, project schedules, task dependencies, and even return on investment (ROI). We use them to determine if a project is worth doing in the first place. For many of us, the idea of not estimating a project is like riding a bicycle without handlebars, but despite that fear, the #NoEstimates momentum continues to grow. The case is being made that estimates are inherently inaccurate and wasteful, therefore having a negative impact on the project. And so more and more project managers in the software industry are hanging up their planning poker decks and throwing estimates to the wind.
When asked about the usefulness of estimates in a 2015 interview with InfoQ, Vasco Duarte said, “The assumption is that estimates can be made reliable on a large scale (across the whole IT industry), however that is not supported by the evidence we see.” As a project manager I can attest to the concern about the accuracy of estimates. I am frequently asked to make decisions about work with laughably little information on hand to inform my estimate. When put in that situation, it’s hard to have much confidence in the numbers I am generating. Duarte goes on to discuss how stories from the backlog are selected for sprints in order to achieve specific goals rather than to satisfy an arbitrary number. In this way, items can flow back and forth out of the backlog as long as the eventual target is met. “A goal could be something like: improve performance of X to 500 transactions per second. Such a goal does not stipulate the ‘how’, only the ‘why’. The stories we take into the sprint are subject to that goal, not the other way around.” He anticipates and even embraces scope creep, calling it “value discovery.”
Woody Zuill compares estimating a software development project to trying to estimate a game of chess:
“…even if we had all the information, there are many variables and a lot of stuff we have no control over…I don’t want to be spending time on work that has no value, causes misdirection and waste, and potentially destroys any chance of being effective. That is painful. There are MUCH BETTER WAYS to approach software development.”
Whoa there, Woody…shots fired! And Neil Killick took an even more radical approach in his blog post introducing the concept. He purports that estimates are not only useless, but they are “actually destructive” because they pressure developers into overestimating story points in order to give the appearance of more work getting done. This harms project transparency and can potentially make for a toxic work environment. So, as you can see, these #NoEstimates guys are serious. They believe very strongly that estimates are pretty much a waste of time and we project manager types should avoid them at all costs.
But wait! There are two sides to every story, and in this case there are some very vocal opponents to the #NoEstimates movement. Glen Alleman, author of the PM blog Herding Cats, goes so far as to call it a pseudo-science:
“Think about the conjecture. How would you assess a decision in the presence of uncertainty without making an estimate of the outcome of that decision…Such a process defies the principles of microeconomics of decision making. Defies the principles of managerial finance in the presence of uncertainty. Defies the principles of closed loop control systems in the presence of stochastic non-stationary systems. It simply defies the principles of logic.”
I know what you’re thinking…the #NoEstimates guys are gonna need some aloe vera for that sick burn! But he does have a point. How can you make a decision about something without solid information to inform that decision? As project managers, we have to do that all the time, and just because you say you aren’t using estimates doesn’t mean that you aren’t. When faced with a decision that contains inherent uncertainty, you must base your decision on something. That something almost certainly will be some form of estimate. Really, it’s just a matter of defining the fidelity of the estimate you are using to make your decision. When giving examples of tracking the progress of a #NoEstimates project, Vasco Duarte states that he will project or forecast the rate of delivery of features from the backlog. What is that if not an estimate?
Peter Kretzman is also an outspoken critic of the movement and shares his thoughts in his series The Case Against #NoEstimates:
“Setting achievable, concrete goals is healthy, in business and in life. Making solid, reasonable commitments is healthy. Taking responsibility for meeting one’s commitments all or at least most of the time is natural and should be encouraged. And if you’re perceived as constantly wailing that you’re different and special, in fact so special that you believe you can’t really be expected to state when you’ll be done? That’s a non-starter.”
Man…these guys don’t mess around, do they? What Kretzman is getting at is that estimates are exactly that, they’re estimates. We aren’t being asked to predict the future, just provide our expert judgment on what we think is reasonable given the information we have on hand. It happens in pretty much every other industry. Life is run on estimates. Corporations estimate quarterly earnings, overhead, and profit. Families estimate monthly expenses to plan their budgets. Nonprofits estimate seasonal giving to plan their upcoming programs. I estimate my commute to work each morning so I can get to the office on time. We estimate every day. If that’s the case, then what is it that makes estimating in software development so bad? Kretzman goes on to challenge the #NoEstimates movement, asserting that they have yet to provide any reasonable examples of enterprise-level projects successfully run on the #NoEstimates model.
And he may be right. I must admit that I have some trouble picturing how this process would scale to larger endeavors that would require a business to forecast ROI before project approval. But even the most die-hard #NoEstimates fanatics have softened a little over the years. Many have started to recognize the value of estimates as a tool for project managers, even if they feel like that tool is vastly overused. It reminds me of the old saying “when all you have is a hammer, every problem looks like a nail.” Project managers just need to keep in mind that estimates are not the only tool we have in our belt. Ambiguity is an uncomfortable place for most people, and estimates are one way project managers can deal with ambiguity, but we have others. The estimate will probably never go away as a method for forecasting project costs and timing, nor should it. We just have to always keep an open mind to new techniques or different ways of achieving that same goal.