The only thing that matters when planning a Sprint
Crafting a clear and overarching Sprint Goal during Sprint Planning
Boxer Mike Tyson once said:
“Everybody has a plan until they get punched in the mouth.” — Mike Tyson
In military warfare a similar saying exists:
“No battle plan survives contact with the enemy.” — Helmuth von Moltke the Elder
No matter how much time you spend planning, you can never make a plan that covers everything. A plan that covers all scenarios and every (re)action of the enemy. Reality is too complicated and unpredictable to fit in a plan.
Unless you are the A-Team of course.
To address the complexity and uncertainty of reality, the army accompanies all battle plans with a Commander’s Intent (CI).
The Commander’s Intent of the D-Day operation for Britain, Canada and the U.S. was:
To secure key bridges, road junctions and other locations in Normandy that would allow the ground invasion forces to advance inland.
When all goes to hell and the plan crumbles after a confrontation with reality, armed forces can fall back on the Commander’s Intent. The CI explains the purpose and the goal of the mission. The why that will never become obsolete even if the original plan does.
The Commander’s Intent prevents following the plan to become more important than meeting the objective of the plan.
By understanding the purpose and goal of a mission, the people on the ground enjoy the freedom to make decisions in the spirit of the original plan. It promotes teamwork and incorporating new information into battlefield decisions.
The result is a better plan and a better outcome.
In Scrum, each Sprint the Scrum team makes a plan to finish a selection of Product Backlog items. The Scrum equivalent of Commander’s Intent for the plan of each Sprint is called the Sprint Goal.
Sprint Planning: resist the urge to focus on the Product Backlog
As Product Owners, we spend a lot of time crafting the perfect Product Backlog. A carefully curated list of items that will make our product vision a reality.
When Sprint Planning starts, it is hard to resist the temptation to focus on the Product Backlog. To just make a plan for completing the selected backlog items. After all, we have spent so much effort on having a clear and refined Product Backlog.
Starting with the Product Backlog is a mistake.
By putting the Product Backlog first at the Sprint Planning, the plan and the work selected become more important than the outcome you want to reach. The Sprint Goal risks becoming an after-thought resulting from the work you have selected.
As Product Owners, we have the responsibility to start with the end in mind. To focus on the outcome of the Sprint, instead of just presenting the steps and the plan to get there.
“The problem with specifying the method along with the goal is one of diminished control. Provide your people with the objective and let them figure out the method.” — L. David Marquet
By crafting a clear Sprint Goal we can convey the Commander’s Intent of what we want to achieve this Sprint. We empower our team to make the right decisions during the Sprint without needing us.
Sprint Goal: the Commander’s Intent of the Sprint
The Sprint Backlog, the selected backlog items plus the plan for delivering them, should be flexible. The Sprint Goal, after the whole Scrum team reaches agreement on the goal, should be inflexible.
This is why the only reason for cancelling a Sprint is if the Sprint Goal becomes obsolete. As long as the Sprint Goal matters, the team has a north star to help guide decisions.
Beginning teams start their Sprint by agreeing on the amount of backlog items they can complete during the Sprint. Little or no time is spent on making a plan for finishing the Sprint Backlog.
Good teams take it a step further and make a plan so they can track their progress each day of the Sprint. If there is a Sprint goal, it is an after-thought to summarize what kind of items are present in the sprint.
Great Scrum teams start with the Sprint Goal and collaborate with the whole team to craft a final version. The selected Product Backlog items and plan follow from the Sprint Goal.
Next time you plan a Sprint, try to start with the Sprint Goal
“Goals transform a random walk into a chase.” — Mihaly Csikszentmihalyi
Update 02–02–19: José Francisco Carle Carrera made an amazing picture that summarizes this article in a better and more beautiful way than I was able to do. So I decided to include his work here, after receiving his blessing.
Now back to the original conclusion for those that prefer to read.
The army knows reality is too complicated and uncertain to fit in a plan. To address this all battle plans are accompanied with a Commander’s Intent. The Commander’s Intent explains the goal and purpose of the original plan.
The Commander’s Intent makes sure that:
- Meeting the objective is more important the following the plan.
- When the plan fails, everybody has enough information to come up with a better plan.
- When the plan fails, everybody has enough information work together towards the same goal.
The Sprint Goal is the Commander’s Intent of Scrum. It allows the team to come up with a plan and selecting the Product Backlog items that will meet the Sprint Goal.
Starting with the Sprint Goal has many benefits:
- Focus. A clear Sprint Goal helps decide what is important to tackle and what not during the Sprint.
- Teamwork. Clarity on the outcome to be achieved promotes teamwork. Everyone understands what needs to be achieved at the end of the Sprint.
- Autonomy. The team is empowered to make the right decisions by understanding what outcome needs to be reached at the end of Sprint.
- Self-organisation. By starting with the Sprint Goal, you give the team the opportunity to select what items to include and come up with a plan for meeting the goal.
- Commitment. By starting with the Sprint Goal and giving the freedom to the team to determine the Sprint Backlog, you receive more buy-in to the Sprint Goal, as they are involved with the whole plan from the start.
- Flexibility. It will provide the team flexibility on what functionality is implemented during the Sprint.
So next time you start with your Sprint Planning, resist the urge to present your beautiful backlog. Present a clear Sprint Goal and work together to make it final. Let the selected Product Backlog items plus the plan for completion flow from the Sprint Goal. The plan will be better, the end result will be better and the people will be happier as well!
