The #NoEstimates movement is an interesting thing. If you haven't heard about it, take a look at #NoEstimates hashtag on Twitter, read these articles from Ron Jeffries (article 1, article 2, article 3) or buy (and read) the excellent book written by Vasco Duarte.

Let me make a summary for you: we fail making estimations. A lot. Take a look at famous CHAOS report if you need more evidence. Agile methodologies improved the numbers a bit but not too much (I bet the numbers are going down again because everybody is "agile").

Failing making estimations is not bad per se. The problem is the use we give to estimates:

[caption id="attachment_274" align="alignnone" width="502"]Estimates as deadlines Estimates as deadlines[/caption]

And we usually do that when we know less about the project: before even starting it. Before starting a project maybe we have a good definition of the most important stories, but the others can be vaguely defined (which is good). So we should be able to estimate with some precision the first and most important stories of the backlog (which we already know we must implement), and we will produce very bad estimations for the vast majority of the backlog. Why are we estimating then?

There can be multiple answers to the previous question: we need to know if you will be able to do the job within the budget, we need a release date, etc. And all of them are fair. But the problem is that our answer is just a guess, it is not based on any empirical data. You can claim that you are an expert project manager with more than 15 years of experience, but you have to admit that this is the first time that you're developing this project for this client with this team.

Don't our clients deserve a better answer? Yes, of course. Why don't we use real data from the project to answer these questions? Why don't we talk with our client and ask to work on the project for three or four sprints and use that data to make a projection? Why don't we work on splitting stories in order to make them similar in size and avoid estimating and just count them (and increase our knowledge about them)?.

It sounds quite reasonable to me.

My main conclusions are the following ones:

  • Question all your practices. Estimations, retrospectives, testing, daily meetings... all of them. Are the practices giving value to you and your client?
  • Build trust with your client. If your client trusts you, probably you won't need estimations.
  • Work on slicing stories. Estimate them after doing it if you want, but you'll gain knowledge about them, and about your domain if you do it. You'll be able to deploy them sooner and shrink the feedback loop.
  • Use real data to make predictions. Real data beats guesses. Always.