John Stenbeck, in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates a grid of all 87 processes used in Agile project methodology. They are divided into five process groups and 7 knowledge areas.
Today I am continuing to cover process 3.7, that is, the seventh process in the third knowledge area of “Adaptive Planning”, which just happens to fall in the “Planning” process area.
In the last post, I talked about general principles behind agile estimating, and I continue that discussion here. Specifically, I want to talk about the “cone of uncertainty.” While customers interact with the team, their focus oscillates back and forth as they find the real boundaries of the problem and clarify the solution to it. So stakeholders need to meaningfully engage with the team in order to move through the “cone of uncertainty” and find the optimal solution.
How does this effect agile estimating? As the amusing diagram shows above (taken from agilenutshell.com), it’s best not to make promises about how long it will take or how much it will cost to complete a project while the parameters of the solution are still being worked out (the “skull and crossbones” section of the graph). Only when the solution starts to be relatively well defined can you be in a better position to make promises based on estimates (the “sunshine” section of the graph).
Understanding the cone of uncertainty requires that you understand two dynamic forces which seem to be opposing forces, for those who are new to agile frameworks. These two forces are:
- Organizations need stability–in order to plan the marketing and other business functions that will be affected by the solution being developed. So the definition of what is being developed needs to be stabilized.
- Agile teams need flexibility–in order to define how the solution is developed.
How are these supposedly opposing forces reconciled?
- Flexibility is provided with the roadmap (program level) and release plan (project level) timeboxes, as well as product backlog grooming; stability is provided with the iteration timebox (and committed iteration backlog).
- Customers need to be able to change their minds about requirements during the project. Stability in the short term is provided during the sprint, when requirements are not allowed to change, and flexibility in the long term is provided outside the sprint. The customer/proxy must then be committed to postponing changes until the end of any given iteration.
Another tool related to agile estimating is the Feature Breakdown Structure (FBS), the analogy of the Work Breakdown Structure in traditional PM. This is discussed in the next post.
Filed under: Uncategorized |
4squareviews 
Leave a Reply