There’s a meme getting traction in the Agile community: #NoEstimates . It’s the idea that putting effort into estimating user stories is mostly a waste of time. I agree that, in general, in most cases, estimates are inaccurate.
Especially early in a project, these estimates can be a total wild-ass guess (hereafter “WAG”) and have no basis in reality.
Prominent blog posts that explain and advance the #NoEstimates idea are listed at the end of this post. [4,5,6].
Value, Cost and Risk
Projects are funded and authorized by those who have an interest in value, the cost of obtaining that value, and the risk associated with attempting to obtain that value.
- The value is the benefit, advantage or other gain that occurs as a result of building a feature, eliminating technical debt, and the like.
- The cost is the total sum of cash and non-cash payments required to create value.
- The risk is the possibility of loss of cash and non-cash assets (example: employee morale, employee retention, time, etc) associated with investing time and effort in the creation of value.
Now, for most typical organizations who are new to Agile, it is unlikely that authority will enjoy being told “estimates are a waste of time, so we are not doing them.” The most progressives organizations are already OK with this idea. The problem of course is that 90% of the Agile work going on is going on inside relatively unprogressive organizations, inside orgs that are learning. Selling #NoEstimates is a tough sell in that spot.
Few if any people in the Agile community discuss risk when discussing value and cost. (Chris Matts, a man who works on trading systems for a living. is one notable exception here .)
Regarding risk, the main thing risk managers do in (for example) hedge funds is define the risk . This is usually defined by ‘stops’ that limit loss to a known, predictable number in dollar or percentage terms. Key to getting this number is knowing the cost of the trade. For example if you want to limit risk to not more than $50 and not more than 10% of the trade, the dollar cost of the trade cannot be less than $500. That’s the cost of creating and maintaining the trade. Without knowing the total cost of the trade, it is hard to manage (“limit”) risk in any rational way.
The Larger Concern
The larger concern is the fact that team members gain a substantial amount of team learning via discussions about estimates. During estimation, a given item in a backlog gets discussed, and the team members learn about that work (and each other) as they discuss it. One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.
It’s true that most estimates are waste. It’s rational to believe this, and there are many good blog posts elsewhere that explain “why”. You can examine them by investigating the Twitter hash tag #NoEstimates (see below).
People behave irrationally and of course project sponsors and people who fund these projects are no exception. Many organizations in fact have built up various departments and policies that support and in fact demand information like estimates before a project is funded.
The problems that remain to be solved are:
- How exactly to explain to project sponsors that the cost component delivered as an estimate is not really valid, and therefore is waste?
- How to encourage the same level of team learning that takes place during the estimation process?
Most estimates may be waste, but for most coaches and clients, estimates are a necessary fact of life, especially in the early part of any move to Agile.
 #NoEstimates Tweets on Twitter
 Chris Matts blog (blog posts and links)
 Trading Risk: Enhanced Profitability Through Risk Control (book)
 Five Reasons You Should Stop Estimating User Stories (blog post link)
 Story Points Considered Harmful (blog post link)
 #NoEstimates HashTag Explained (blog post link)