Improving estimates – the #NoEstimates view

At the OOP 2014 conference, Vasco Duarte (@duarte_vasco) gave a talk on #NoEstimates. I heard the term before and I was curious. So I went to the talk.

He said the question is „How can you predict the release date of your project without estimates?“. Vasco argues that to commit to an estimate is to commit to a plan. But with #NoEstimates, one would commit to customer value rather than to following a plan. Another aspect is that estimates are often political and that they often encourage to push „for more“.

One precondition for applying #NoEstimates is to have a stable software development process. That means that for the last 3 or 5 sprints, the number of delivered stories are within certain limits (= velocity stability). This implies that you have rather short sprints. If your „sprints“ are actually mid-range runs (like 2 months), you only know after about half a year whether your velocity is stable.

With #NoEstimates apply the following steps:

1. Select most important piece of work
2. Break it down into risk neutral chunks of work (chunks are small, like one person day)
3. Develope each piece of work
4. Iterate and refactor

So how do you answer the question for the release date? If you know the number of stories that are needed to implement and you assume that your process remains stable then you can simply extrapolate how many sprints you are going need and hence when you are going to release. Take the average of your historical data and project it into the future.

To me, this is a no-brainer. If you have historical data and a stable process then you don’t have to estimate, you can simple extrapolate from historical data.

To me, #NoEstimates has a number of important preconditions:

• sprints are short
• velocity is stable and is likely to remain stable
• probably, stories should be about the same size

One interesting aspect was that the number of stories seems to be a better indicator for release date than story points. Vasco showed data from several projects to support that.

As I said, if the preconditions are met, this is a no-brainer. It is like driving on the highway at about 130 km/h for the last 15 minutes (stable process). Then we will arrive at our destination that is 130 km away in 1 hour. No need to estimate, simply extrapolate.

Vasco picked on Steve McConnells book „Software Estimation: Demystifying the Black Art“ because McConnell would show that estimates are often poor and he’d recommend „better estimates“ (instead of „NoEstimates“). Having read that book myself I think this was unfair but I will leave this for another blog post.

The talk was interesting and now I know what #NoEstimates is about.

On a side note, I was reminded of the talk „Predictability and Measurement in Kanban“ by David Anderson. If I remember correctly, predictability in Andersons talk relates to system stability in Vascos talk.