Use 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.
The idea is that estimates made at the beginning of a project will be limited in their accuracy. As you reduce uncertainty in the project, the estimates can gradually become more precise. Throughout the project, the concept, requirements, and design will evolve to give a much better idea of the feasibility, timeline, and costs of the project.
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
In traditional project management approaches like the Waterfall approach, the project is expected to follow a detailed project plan that was created at the beginning of the project. In contrast, Agile methodologies prioritize the process of planning itself. These methodologies take into account that initial plans are based on the best information available at the start of the project, and that this information is often incomplete or can change as the project progresses.
embracing change along the way
Agile approaches accept and even embrace the fact that projects are dynamic. As a project develops, new information and insights emerge, leading to changes in requirements, scope, or priorities.
continuous planning over a one-off plan
Instead of creating a detailed plan at the beginning and sticking to it regardless of changing circumstances, Agile methodologies require ongoing planning throughout the project lifecycle.This means regularly revisiting and revising the plan based on the latest information, learnings from previous work, and feedback from stakeholders.
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 the daily level:
Release Level Planning: Outlines the major goals and timelines for product releases.
Sprint Level Planning: Involves more detailed planning for shorter cycles (sprints), focusing on what will be delivered in the next few weeks.
Daily Planning: Allows for rapid adjustments to address immediate issues.
Plan in layers with 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. To dive deeper into user stories, take a look at the course Write Agile Documentation: User Stories & Acceptance Tests.
In order to deliver major features, you 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 the work needed to deliver these items will 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 does Agile Planning Work?
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 provides feedback by asking how you can meet objectives and what you learned during the last sprint. This helps manage uncertainty.
Let's Recap!
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
Now that you know about planning and estimating in Scrum, it's time to take a look at a particularly effective way to estimate task completion. Let's go!
