The Trouble With Release-Scale Estimation

With practice most agile teams get quite good at estimating individual stories, and hence at iteration planning.

However trying to extend the same ideas to the backlog and release planning often results in something like this...





Eventually (and possibly with the aid of a gun to their head) the team may come up with some numbers. Which then get used..



Project managers generally need release-scale estimates, and a lot of thought and effort has been expended in coming up with methods to provide them. Many, in the opinion of this author, are just a bunch of hocus pocus. Some work well enough within a team that understand their limitations and the assumptions that went into them. But when people start drawing charts and quoting story-point totals and 'burn rates' out of context then they're generally talking complete nonsense.

It remains a fundamental fact that you cannot accurately estimate requirements which aren't accurately specified - and if you are doing agile development and requirements are still in the form of vague epics on the backlog then they are not, by definition, accurately specified. If future requirements have to be worked out down to detail then you're no longer doing agile development - you're back in the waterfall world of the upfront specification with all the problems that implies.

So what's the answer? Really, the best answer is not to worry about it. If you prioritise properly, build the essentials first and aim for coherent on-time releases you perhaps don't need to bother with burn charts and all that jazz. Of course, some sort of estimation is still required, and there you can't beat experience and time-honoured tooth-sucking skills...