If you are involved in Agile development and still haven’t read “Agile Estimating and Planning” by Mike Cohn, I strongly recommend you find the time to have a look at this valuable book. What I found especially interesting is the part explaining why the traditional approach to planning fails. According to him, those are the reasons why:
1. IT IS PLANNED BY ACTIVITIES RATHER THAN FEATURES
For the client, what counts are the features and therefore, planning should focus on those features.
- The work never ends early. “Work expands so as to fill the time available for its completion.” Parkinson’s Law (1957)
- Each delay is transmitted to the schedule. Many tasks/activities depend on each other sequentially. If one is delayed, it is likely that the date of “general” delivery will be affected.
- Activities are not independent. For two activities to be considered as independent, the time dedicated to one shouldn’t affect the time dedicated to the other. Unfortunately, it is often assumed that delayed activities tend to be compensated with the rest.
2. MULTITASKING ADDS DELAY
“The time spent on tasks that add value decreases when operating in more than two tasks at once.” Clark and Wheelwright (1993
Assign two tasks; it can be helpful because if you get stuck in one, you can continue with the other one. If you have three tasks or more, the time spent in moving from one to another becomes significant.
3. THE FEATURES ARE NOT DEVELOPED ACCORDING TO THEIR PRIORITY
Traditional planning wrongly assumes that all tasks will be completed. It is for that reason that they often prioritize tasks according to what is appropriate to the development team. If they are late, the team may be forced to discard features that might not be the ones that provide less value to the business.
4. THE UNCERTAINTY IS IGNORED
In the traditional planning approach, uncertainty is not acknowledged. It wrongly assumes that the initial requirements analysis will lead to a complete and perfect product specification.
It also assumes that users won’t change their minds, and new needs won’t arise throughout the project. The goal is to make accurate estimates on yet inaccurate work.
At the beginning our estimates should reflect this uncertainty and, as the project advances, uncertainty and risk will decrease.
The best way to deal with uncertainty is by delivering working software every iteration.
Cone of Uncertainty: Representation of the“evolution of the range of uncertainty” throughout a project. As the project progresses, the range of uncertainty is reduced.
5. ESTIMATES BECOME COMMITMENTS
“One estimate is a probability and you can not make a commitment based on a probability.” Phillip Armour (2002)
We can say, for example, that for an average project, an estimate between one week and ten years will lead to a probability between 0% and 100%.
