What’s wrong…? After years of discussing estimation/sizing of the effort needed to bring a user story from vague ideas to proven value – it seems that as a community we are not any closer to agreeing on even the basics. Not that it is a goal to agree, but it would be nice to at least send a roughly similar message to our dear clients and co-workers, who are constantly the “victims” of our ongoing process experiments. What bothers me the most about many of the traditional Agile ways of doing estimation is that both the process of doing estimates and the way they are used seem to be imposing and constraining the process rather than supporting it.
In this essay I will try to present my current view on estimation and how I think we should move forward in a way that is not only closer aligned with recent developments in the Agile community but also a way that makes it easier, less time consuming and more valuable. Having battled successfully (and in some cases not so much) with the theme of Agile estimation and forecasting for the past 9 years – this is what I have concluded so far:
- You will never get estimates right on the individual user story level. Estimates are a distribution of likelihood of hitting your average cost – NOT single numbers. So expect them to be wrong and use data to show the nature of your distribution.
- Variability pooling means that even if individual estimates are highly uncertain you can be predictable overall if you find yourself in a stable environment.
- What makes you predictable (or unpredictable) has more to do with your environment than estimation/sizing, but you do need to be disciplined about data collection to stand a chance at predictability. A new team on a new product using new technology will be highly unpredictable no matter the estimation technique, triangulation exercises or the amount of detail provided. The cone of uncertainty will be reduced as you get the first data points and the sooner you can test your assumptions the better – both in terms of cost and effect.