The application of the Cone of Uncertainty to iterative projects is somewhat more involved than it is to sequential projects.
If you’re working on a project that does a full development cycle each iteration—that is, requirements definition through release—then you’ll go through a miniature Cone on each iteration. Before you do the requirements work for the iteration, you’ll be at the “Approved Product Definition” part of the Cone, subject to 4x variability from high to low estimates. With short iterations (less than a month), you can move from “Approved Product Definition” to “Requirements Complete” and “User Interface Design Complete” in a few days, reducing your variability from 4x to 1.6x. If your schedule is fixed, the 1.6x variability will apply to the specific features you can deliver in the time available rather than to the effort or schedule.
What you give up with approaches that leave requirements undefined until the beginning of each iteration is long range predictability about the combination of cost, schedule, and features you’ll deliver several iterations down the road. Your business might prioritize that flexibility highly, or it might prefer that your projects provide more predictability.
Many development teams settle on a middle ground in which a majority of requirements are defined at the front end of the project, but design, construction, test, and release are performed in short iterations. In other words, the project moves sequentially through the User Interface Design Complete milestone (about 30% of the calendar time into the project), and then shifts to a more iterative approach from that point forward. This drives down the variability arising from the Cone to about ±25%, which allows for good enough project control to hit a target while still tapping into major benefits of iterative development. Project teams can leave some amount of planned time for as-yet-to-be-determined requirements at the end of the project. That introduces a little bit of variability related to the feature set, which in this case is positive variability because you’ll exercise it only if you identify desirable features to implement. This middle ground supports long range predictability of cost and schedule as well as a moderate amount of requirements flexibility.
This material has been adapted from Software Estimation: Demystifying the Black Art, © 2006 Steven C. McConnell, and has been used with permission.
<Back to Part 1
Resources on Software's Cone of Uncertainty
Construx's Cone of Uncertainty poster
Software Estimation In Depth seminar
Construx's estimation consulting
Other estimation resources