Are you ready to get the most out of sprint planning? As a project manager or product owner, it's up to you to make sure everyone is on the same page and to deliver results.
So it's time to declutter the chaos and nail those success criteria with this ultimate guide that will make your sprint planning so organized you can give Marie Kondo a run for her money!
In this comprehensive guide, I'll walk you through everything you need to plan successful sprints—including setting a sprint goal, how to prepare for the sprint planning meeting, assembling the meeting agenda and other best practices.
What Is Sprint Planning?
The sprint planning event signals the beginning of the sprint. Both the sprint and sprint planning are elements of the Scrum methodology, and the goal of sprint planning is to define what should be accomplished in the coming weeks and how it will be done.
In the sprint planning meeting, the whole team comes together to plan the work of the upcoming sprint cycle. By the end of the meeting, the sprint goal and the tasks to be completed should be set.
Depending on the length of the sprint, the planning meeting lasts between two and eight hours. It should be timeboxed according to the length of the sprint (ex. maximum 4 hour meeting for a two week sprint).
Commonly, the sprint planning meeting is usually structured in two parts:
- The first part clarifies the “why” and “what” of the sprint: the team sets the sprint goal and agrees on what will be done. It selects the backlog items from the product backlog that will be processed in the sprint.
- The second part is about the “how”: the developers discuss the details of the individual backlog items and break them down into tasks. Each task is tailored to be completed in a business day or less.
Who Is Involved In Sprint Planning?
In short, the entire Scrum team, meaning the product owner, Scrum master, and developers.
The sprint planning is a regular Scrum event (aka Scrum ceremony), and this meeting usually takes place at the beginning of each sprint.
Usually, teams have a fixed time frame for their sprint (ranging from 1 to 4 weeks), so the sprint planning date can be set well in advance and scheduled as a regular meeting in the team's calendar.
The Scrum master (called an agile coach in some teams) ensures that the meeting takes place, ensures that the agreed workflow is followed, and that the participants develop a common understanding of the sprint goal. Read about Scrum masters vs project managers here.
Sometimes stakeholders from the company will join as consultants if they can provide an important perspective or helpful knowledge. As a rule of thumb, the Scrum team keeps to themselves during the sprint planning and has already compiled all the necessary information and requirements ahead of time.
Goal Of The Sprint Planning Meeting
During the sprint planning, the product owner and the developers agree on a specific sprint goal. The sprint goal describes the result or the outcome of the new sprint that the team is working on. It is a short-term milestone on the way to the final product.
The goal is that at the end of the sprint, there is a deliverable product increment that already offers a benefit to customers.
How To Prepare For The Sprint Planning Meeting
One of the most important preparations for sprint planning is regular backlog refinement, in which the most important entries are updated. For an effective meeting, the product owner (PO) should also prepare the following things:
- Ideally, they have included the findings of the last sprint review and sprint retrospective, as well as stakeholder feedback in the backlog.
- Pre-definition of sprint goal with associated prioritized backlog items that can be discussed in planning
- Overview of the work already done
Also, before any planning can take place, an assessment of the team's capacity for the next sprint is needed, which is often carried out by the Scrum master.
In doing so, they take into account the average performance of the team (team velocity) over the last sprints and also considers known absences of individual team members (holidays, further training, etc.) when estimating the available team capacity. I will cover this in more detail below.
What Is The Backlog?
If you're a product owner, chances are that you've heard of the term "backlog" more times than you can count. But what exactly is it? Sure, on some fundamental level, we all know what it is—a list of tasks or functionalities that need to be completed.
However, when it comes down to nitty-gritty details like the difference between a product backlog and a sprint backlog, things get complicated quickly, so buckle up and let's dive in!
Product Backlog vs Sprint Backlog
The Scrum team collects all user stories, epics, and tasks that are required to create the final product in the product backlog. And the product owner prioritizes the backlog items so that the stories with the highest value for the customers are at the top. This prioritization is usually done together with the developers.
However, the product backlog is not a final list that is created at the beginning of the development phase and then processed. No, this list is constantly growing and changing over time.
It grows through both the knowledge gained in the sprints, and through new requirements that arise going forward. Therefore, regular refinement of the backlog is necessary in order to address these changes.
For example, let’s say that the product backlog consists of all stories that are necessary to create a website, ex. the homepage, contact form, and product pages. If the marketing team suddenly realizes that they absolutely need a blog section on the website, then this can be included in the backlog and prioritized accordingly.
In comparison to the product backlog, the sprint backlog contains only the backlog items selected for the current sprint and an overall sprint goal.
How To Estimate Items In The Backlog
How much work can a team complete in the sprint? This is one of the central questions that developers have to answer during sprint planning. In order to be able to make a prediction, they make an estimate.
This can be quite challenging as the team is dealing with many unknown variables. However, over time and with the experience gained from completed sprints, the team gets better and better over time with their estimates.
How To Calculate Team Velocity And Capacity
Before the estimation can begin it’s essential to know the average performance of the previous sprints (velocity) and the available team capacity for the upcoming sprint, which might be reduced due to training, vacation, etc.
Based on these considerations, the team estimates the amount of work (velocity) that it can handle in the sprint, then evaluates the individual backlog items and chooses how many of them to include in the sprint backlog.
Let’s say the average velocity was 40 story points over the last couple of sprints (2-week cycle), and no significant reduction in the availability of team members is expected, then the team will plan based on keeping this same velocity (ie. backlog items selected for the upcoming sprint will fill around 40 story points).
Estimation Methods: A Brief Overview
Are you looking to better understand the art of estimation? With different methods and variables at play, it can often feel like an intimidating topic—but don’t worry! By understanding the basics, you'll become well-equipped to estimate your backlog in no time.
Story Points
Many agile teams working on long-term projects estimate their velocity in story points.
Story points are an abstract unit that the team uses to measure the effort required to complete a backlog item. This is based on three criteria:
- Amount of work: How many subtasks must be completed to complete the user story?
- Risks and Uncertainty: Are all requirements clear or could there be unexpected delays and changes?
- Complexity of the story: Are individual subtasks linked to each other, so that the complexity of the story increases? And are there dependencies outside of the team?
The Fibonacci Sequence & Prime Numbers
Agile planning with the use of the Fibonacci sequence and prime numbers helps teams make forecasts that are not just intuitively based on optimism, but rather informed by principles of numerical logic.
If a user story has many variables and is complex or large-scale in its scope, then assigning it a higher number on the Fibonacci scale means that the team is prepped to commit enough resources and effort to see it through—because they already know the amount of work inherent in such an undertaking.
On the other hand, stories with fewer variables or simpler outcomes get assigned lower numbers—thereby allowing for tighter budgeting of time and energy. In short, agile planning takes hopes and dreams off the boardroom table and puts some hard, tangible numbers there instead!
However, please keep in mind that story points are not necessarily comparable across software development teams, as each team estimates the scope a little differently. That means, what team A estimates to be a 5 SP story could be an 8 SP story for Team B.
Story point estimation is also suitable for smaller teams or projects, as with this method, the team evaluates the tasks based on the complexity and time it takes to process them. Other techniques include estimating the effort based on T-shirt sizes or the planning poker method.
T-Shirt Sizes
Estimating backlog items with T-shirt sizes is an interesting approach to helping prioritize project tasks. Instead of assigning an exact number of hours or days to a task, you can assign it one of four size types (small, medium, large, and extra-large) depending on its degree of complexity or uncertainty.
It's a simplified yet surprisingly effective way of ensuring that the right tasks get done at the right time—whether you're dealing with small, medium or large-scale projects, all you need to do is pick the size that fits. Just make sure that everyone involved in the project agrees on how each size corresponds to a specific estimated level of effort!
Planning Poker
If you're looking for a clever way to estimate your backlog items, why not try planning poker?
It's a popular technique that has been around since 2002 when James Grenning coined the term.
The approach is simple: team members anonymously provide their estimates by choosing cards from the deck of planning poker cards which represent different estimations (ie. the estimated number of story points for the item).
This encourages everyone to articulate their opinion without fear of judgment or ridicule from others. Once all team members have entered their estimates and a consensus is found, the team moves on to the next item.
The Sprint Planning Agenda
The planning of a Scrum sprint usually follows the following agenda:
- The product owner (PO) presents his predefined sprint goal and shares his idea of how to increase the value of the product in the upcoming sprint. The final sprint goal is defined jointly by the product owner and developers.
- The PO names the (prioritized) items from the product backlog that should be implemented to achieve the goal.
- The team estimates the effort for the individual entries, if this has not already been done beforehand (ex. in the backlog refinement). If necessary, the team refines individual entries or content (ex. acceptance criteria).
- The team selects the product backlog items that it will deliver by the end of the sprint. At this point, the product owner discusses the tasks to be completed with the developers based on customer value and effort. Are the items selected sufficient to meet the sprint goal and create value for the customer? In the end, the developers decide for themselves how much work they take on in the sprint. Important: This selection is not a commitment to the product owner and stakeholders, but a prediction based on the effort estimate and the average team velocity.
- The developers then get together to break down the selected backlog items into smaller tasks. At best, these work packages are tailored to be completed in a day or less.
- The sprint backlog consists of the jointly agreed sprint goal, the backlog items to be processed, and the plan for how these are processed.
- Many teams visualize the sprint backlog and the work to be done in a Scrum board. Each team has its own board and uses different columns to document progress in the sprint. In essence, the most important columns of all boards should be the following three: "To Do", "Doing", "Done".
In practice, many Scrum teams split the sprint planning into two phases:
In the first part, the first four items of the agenda items described above take place. The product owner and team clarify the questions: “Why is this sprint valuable?” and “What will be implemented in this sprint?” The developers do the second part without the PO and deal with how they do the selected work.
Sprint Planning Meeting Agenda Template
Need an agenda template for your sprint planning meetings? Download our clear and straightforward template to quickly get up and running for your sprint planning meetings. You’ll also find a checklist and an email template, for extra convenience.
Time To Marie Kondo Your Sprint Planning Meetings
With this comprehensive guide, you're now set to make the most out of your sprint planning sessions.
By following the steps outlined in this post, product owners are sure to be successful in converting chaos into clarity and helping their team members nail their next sprint. Read more about the Scrum framework and other Scrum ceremonies like the daily Scrum here.
To stay updated with more organizational tips and spotlights on topics related to running effective product-driven projects, I invite you to subscribe to The Digital Project Manager newsletter. From there, we'll continue to bring insights from industry experts and project managers around the world.