An Agile Approach to Planning & Estimating
Estimating and planning are important activities, yet difficult to do well.
In particular, estimates that you generate at the start of a project tend to be less accurate than estimates given toward the end of a project. This can be represented graphically by the Cone of Uncertainty.
Mike Cohn, author of Agile Estimating and Planning, explains how Agile methodologies compensate for this when he described the Agile approach as:
focused more on the planning than on the plan
The Agile approach is not to generate one single plan and believe that it will never change. Rather, begin with a plan and embrace change along the way.
Instead of focusing on a one-off plan, focus on the activity of planning. In Scrum, for example, the framework provides for planning on the release level, the sprint level, and at a daily level.
The Planning Onion
The Planning Onion is a graphical representation of the layers of planning that are built into Scrum.
For example, a team releases a new update of their product every two months. Then:
Every two months you have a release.
If the team does two-week sprints, that is then four sprints per release (because 4 sprints would last 8 weeks).
A two-week sprint would have 10 daily stand up updates.
In this way, Scrum teams use 3 levels of planning.
Release planning
Sprint planning
Daily planning
1. Release Planning
In Scrum, you capture requirements by storing a backlog of user stories. In order to deliver major features, go through the exercise of batching the relevant sets of user stories and estimating them. Note that you estimate the complexity of user stories rather than the time taken to complete them.
Estimation, at this level, involves using abstract units of measurement called story points as the estimate for each user story. In this way, you develop a sense of confidence in how many story points you can do per sprint by measuring past performance (i.e. how many story points has this team historically done per sprint?).
With this approach, you have:
A set of user stories that you would like in your release.
A numerical estimate of each user story's complexity (a number of story points between 1 and 100).
Knowledge of how many story points you have historically done per sprint.
Using this information, you can calculate how many sprints you need to deliver this amount of functionality.
In summary, release planning
Measures capacity in terms of abstract units called story points which are assigned to each user story.
Calculates how many sprints you need to do a batch of user stories.
Calculates the duration of building our release by multiplying number of sprints by length of the sprint (e.g. five 2-week sprints = 10 weeks).
2. Sprint Planning
A Scrum rule is that you conduct a sprint planning meeting for every sprint. The goal of sprint planning is to determine:
What can be delivered in the upcoming Sprint?
How will the work needed to deliver these items be achieved?
The Product Owner begins the planning session by discussing the objective of the sprint (the sprint goal) and which items, if delivered, would result in this sprint goal being met.
The team discusses how it will deliver backlog items. This is done by breaking items into smaller tasks and estimating the rough length of these tasks. By crafting a plan for how it will deliver these items, the team will then calculate how many items it can confidently deliver. Only the team can decide how many items are chosen for the sprint in this way. No manager or product owner can tell the team what it must achieve.
In summary, sprint planning:
Measures capacity in terms of hours.
Attempts to deconstruct each user story into constituent tasks and then estimate the hours required for each task.
3. Daily Planning
The daily stand-up is a meeting facilitated by the Scrum master where each team member is asked:
What did you do yesterday?
What you are going to do today?
Do you have any blockers or impediments?
The goal of this meeting is that each member of the team is aware of the work that each of the other team members is doing and plans to do. Also, each team member can point out if they are stuck or blocked from progressing on their tasks.
Why Agile Planning Works
Agile planning is proven to be very effective because:
There is regular re-planning course adjustments.
The whole team participates in planning which involves experts in the process.
Each sprint provided feedback by asking how you can meet objectives and what you have learned during the last sprint. This helps manage uncertainty.
Summary
In Agile methodologies, including Scrum, the team is focused more on the planning than on the plan.
A plan is an artifact or document, whereas planning is an activity. Scrum encourages regular participation in planning rather than the mistaken belief that plans do not change.
Scrum teams use three levels of planning:
Release planning
Sprint planning
Daily planning
Additional Resources
A nice article on the Cone of Uncertainty
