Using VSTS to Stop Estimating

David Anderson [Agile Management Blog] suggests we stop estimating. He’s premise is that you can burn a fair amount of your capacity generating estimates which we know to be rather inaccurate. Instead we should just tell our customers that based on past productivity, we’ll deliver x (give or take some margin) in the next month. 

I’ll also add my 2 cents by stating that I think estimates are always doomed to fail. In fact, the more granular you estimate, the more likely failure is. Why? Because estimates become budgets when they are converted into task items. When something is estimated at 5 days, very few people take only 4 days to complete the task. Most will take 5 days, and if indeed there are unforeseen problems or complexity, then 6 or 7 days is more likely.

We should really be estimating our work items in some arbitrary scale not tied to time. Both I and Martin Fowler like Josh Kerievsky's term: NUTs (Nebulous Units of Time). So are we stopping estimating? Well not really – just estimating in NUTs instead of time. Furthermore, I think once estimates are created they should be hidden. Draw your line in the sand at the beginning of an iteration of what you think everything is and how it adds up – and then put those numbers into a time capsule until the end of the iteration. They don’t serve a purpose during the iteration other than to maybe act as a budget – and you don’t want that. At the end of your iteration, add up your actual efforts and divide by your estimate of nuts to figure out your velocity – or cost per nut. You can then use that historical productivity (which you should track over time for a team) to put actual time estimates on top of your NUTs for future iterations.

In Visual Studio Team System, the include MSF Agile template includes work item types that include # of hours completed and # of hours remaining. Fortunately you can customize these templates, perhaps to remove these columns and add NUTs and % Completed. This may lead to some impedance with the MS Project integration but maybe if you like this approach you’ll spend less time in there anyway.