I’ve had some interesting discussions lately on the management of work through user stories. A lot of teams, especially those just starting to use agile techniques, seem to have quite a bit of uncertainty around some common topics :
- The theory behind story points and why they are preferred over estimations in hours
- Why story points and velocity are self-correcting measures
- The sizing process and appropriate sizes for stories
The problems with sizing in units of time
I’ve had the opportunity of working on several waterfall projects. I feel blessed to have been in these teams because I now recognize that:
- Most estimations in hours are completely thumb-sucked. Given that software development is an incredibly complex beast, how can we possibly forecast time to be spent on a specific task in an accurate fashion?
- Work break down structures are frequently used to aid in estimations, even though they exasperate inaccuracies of estimation at lower levels.
- As teams typically contain members at different skill levels, how long a task takes depends on which members of the team actually do the work. An estimate based on time does not make sense in this context.
- Traditional project management focuses on getting projects on time, sometimes sending teams on a death march and severely compromising on quality.
- Waterfall based software teams are held to completely inaccurate estimations. The Gantt chart proves to be completely inflexible as the focus of the traditional project manager is on staying true to the original plan.
It should be obvious that I’m not a big believer in time-based estimations. Apart from the above, one should also watch out for the problem of local safety :
If asked how long a small task will take, a developer will naturally not want to deliver it late. After all, this is a small task, it should be on time or the developer wouldn’t be professional. Hence, the estimate will include a buffer to absorb the developer’s uncertainty about the task.
The estimate given by the developer will depend on how confident that developer is that he has understood the task and knows how to perform it. If there is uncertainty in the understanding of the task, then the estimated time to completion is likely to be significantly longer. No one wants to be late with such a small task.