Yesterday, I got dragged into a #NoEstimates discussion on Twitter again. It was a mistake: I really dislike how those discussions usually unfold. With all their half-truths and over-simplifications and attacking straw men and the passive-aggressiveness, most turn basically into a flame war. I think we need a more nuanced discussion, if we even need that discussion at all.
But I could not stop thinking about that discussion. So, here’s another blog about Estimates and other stuff…
Estimates and #NoEstimates
In What is an Estimate, Anyway?, I wrote how I dislike the only definition of “Estimate” that I found in the context of #NoEstimates. As a quick reminder, here it is:
Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made.
And now, I think I know why I dislike it so much. It is not only circular and unhelpful. It invites people to shout No True Scotsman!. And it invites other kinds of flame wars.
An Estimate can mean many different things. It can, for example, mean: “We are pretty confident that we can implement some version of that thing in roughly the same time as some version of that other thing”. As long as everybody involved knows that this is what you mean, everything is fine. As soon as somebody with power misunderstands what the estimate means, you have a problem!
But you have that same problem with any kind of estimate or forecast. And probably even when you don’t do estimates or forecasts at all.
Say you are doing capacity-based forecasts, like some proponents of #NoEstimates would suggest (and which I think are a good idea!). And then somebody misunderstands the forecast and turns it into a commitment. Now, somebody could shout: “No true scotsman! You were not doing proper #NoEstimate, because whatever you had was turned into a commitment, and thus was an estimate!”.
What Could We Do Differently?
Let’s look at the Wikipedia defintion of an estimate again:
An Estimate [is an] approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.
With this definition, we could acknowledge that we are using estimates, whether we estimate things or not. We are also using them when we forcast or “just work on the most valuable things first”.
Then we could talk about for which purposes those estimates are usable, and for which they are not. And we could have a discussion around that.
And if some people in our organization are turning those estimates into commitments, we could talk about how this is toxic for the team and the product. How we are facing the “Feature Factory” and the “Burnout by 1000 Baby Steps” Anti-Patterns in this team. When solving the problem, we may or may not end up with doing less estimation (the activity of estimating things). But there are still estimates.
If this was interesting to you, check out my book Quick Glance At: Anti-Patterns. There, I describe situations that go can go wrong in agile teams. And I am trying to help you find the root causes and start solving those problems.