
I’m a big fan of the debates that have been triggered by #NoEstimates. It’s wonderful to have the dialog, even though many of us often end up talking past each other. I think the root of some of the misunderstanding rests in our assumptions about planning and how we think about risk.
I like the #NoEstimates concept because it challenges us to get away from the belief that we can accurately predict the future. Many of us gravitate towards the idea that if we could just estimate our tasks better, then we would become more predictable. This idea has a lot of appeal because, as professionals, we strongly believe we should be able to accurately assess how long our work will take.
And this is true, broadly speaking. We can get a rough sense of how long work will take. However, there will always be an element of uncertainty remaining, if not in the task itself, then in our environment or circumstances. I experienced a great example of this earlier this week when the power went out just as I was bringing a new printer online. The task duration grew exponentially because of this external block.
If uncertainty is unavoidable then how can we plan? This is the question that I think many discussions of #NoEstimates get hung up on. How should we plan?
Planning is beneficial. It can help us determine the right thing to work on and when to work on it; it can align the work of multiple teams (or multiple disciplines); it can give us a window into how effective we are at delivering value, and how often we do so; and it can ensure that everyone is working together, towards a common goal.
All these outcomes are possible, even in conditions of uncertainty, provided we make planning a recurring activity. If the future is unpredictable, then our plans are inherently flawed. We must revisit them periodically to update them as we learn more. Otherwise, their value decays rapidly with time.
I think an emphasis on planning, not plans, is a natural consequence of the #NoEstimates concept. However, it’s easy to conclude that #NoEstimates makes planning impossible or irrelevant, because how can we plan without any idea of how long a task will take?
The answer is that we can spend just enough time conceptualizing, categorizing, or breaking down the work to make the planning activity valuable. This can be done without estimating. Some teams I work with just get their stories “small enough;” others try to conceptualize them in terms of “units” of work. None of these teams believe they “estimate,” yet they plan effectively.
Closely tied to concerns about plans and planning is how we think about risk. Risk is inherent to what we do; it’s in the uncertainty of our predictions and in the new and innovative solutions we try to bring to customers. When we emphasize regular planning, we recognize this and provide a release valve—a way for risks to be rapidly identified and discussed as a team. This creates an environment where risk becomes a shared responsibility.
#NoEstimates reflects experience with a very different type of environment. Often when development groups are asked for an estimate, what’s really happening is that risk is being transferred. An estimate of two months triggers an expectation of delivery in two months. If there is no commitment to regularly revising this plan, then any uncertainty becomes the responsibility of the team that gave the estimate. Risk is not a shared responsibility; it’s been transferred exclusively to the team, and their estimate was the transfer mechanism.
Not surprisingly, many teams want to avoid this dynamic. Since the estimate was the mechanism that gave them responsibility for all the risk, #NoEstimates has great appeal. If it can trigger a recurring approach to planning, then the team will develop a healthier approach to managing risk and uncertainty.
For some more specifics on how this might work, check out this post from Paul Boos.
2 responses to “Weighing in on #NoEstimates”
Nice post. A few technical touch ups:
All project work is probabilistic driven by the underlying statistical uncertainties. These uncertainties are of two types – reducible and irreducible. Reducible uncertainty is driven by the lack of information. This information can be increased with direct work. We can “buy down” the uncertainty, with testing, alternative designs, redundancy. Reducible uncertainty is “event based.” Your power outage for example. DDay being pushed one day by weather.
Irreducible uncertainty is just “part of the environment.” It’s the natural varaibility embedded in all project work. The “vibrations” of all the variables. This is handled by Margin. Schedule margin, cost margin, technical margin.
Here’s one approach to “managing in the presence of uncertainty”
For my experience in software intensive systems in a variety of domains, #NE is a reaction to Bad Management. This inverts the Cause and Effect model of Root Cause Analysis. The conjecture that “estimates are the smell of dysfunction” without stating the dysfunction, the corrective action for that dysfunction, applying that corrective action, then reassessing the conjecture is a hollow statement. So the entire notion of #NE is built on sand.
Lastly the Microeconomics of decision making in SWDev in the presence of uncertainty means estimating is needed to “decide” between alternatives – opportunity costs.
No Estimates is a solution looking for a problem to solve.
[…] our own experience. Although estimates are a visible aspect of dysfunction (like when they’re used to transfer risk), that does not mean they are the cause. They may only be a surface symptom; discarding estimates […]