Sprint Planning: What Is It & How To Do It?
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! While a good agile project management tool can be very helpful, there is also nothing like human minds and teamwork to create a successful sprint plan.
Therefore, 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?
Sprint planning is the initial phase of an agile development cycle, in which the whole team comes together for a sprint planning meeting to defines the work to be accomplished in a sprint and creates a plan to achieve those goals.
Commonly, the sprint planning meeting is usually structured in two parts:
- 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. Project planning tools with sprint planning features can help organize and prioritize backlog items, ensuring the team stays focused and aligned on the sprint goals.
- The “how” of the sprint: 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 and can be tracked with a task management tool.
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).
By the end of the meeting, the sprint goal and the tasks to be completed should be set and the sprint should have officially started.
Why is Sprint Planning Important?
Sprint planning is important because it establishes a clear direction for a team's upcoming sprint. When done well, a sprint planning session can:
- Establish a clear, shared understanding of project goals and objectives
- Allow teams to prioritize and select work items for the upcoming sprint
- Promote effective resource allocation and time management
- Foster collaboration and communication among team members
Overall, sprint planning is a vital preparatory step in Agile project management. It sets the foundation for a well-organized and efficient sprint, enabling teams to deliver high-quality outputs within the defined time limit.
Who Is Involved In Sprint Planning?
In short, the entire Scrum team should all be involved in sprint planning and attend the Scrum event at the beginning of each sprint. These team members can include:
- The product owner: Provides insights into the product vision, clarifying requirements, and prioritizing the backlog items to be included in the sprint.
- The Scrum master (called an agile coach in some teams and not to be confused with a project manager): Facilitates the meeting, ensures that the agreed workflow is followed, and that the participants develop a common understanding of the sprint goal.
- The developers: Provide technical expertise and insights on the feasibility and effort required to implement user stories.
Sometimes stakeholders from the company will also join as consultants if they can provide an important perspective or helpful knowledge.
How To Prepare For The Sprint Planning Meeting
For an effective meeting, the product owner (PO) should prepare the following things:
- The findings of the last sprint review and sprint retrospective, as well as stakeholder feedback in the backlog.
- An overview of the work already done.
Additionally, the product owner should prepare for a sprint planning meeting by performing several processes, which I will discuss in more detail below. These include:
- Pre-defining the sprint goal with associated prioritized backlog items that can be discussed in planning.
- Regularly refining the backlog, in which the most important entries are updated.
- Assessing the team's velocity and capacity for the next sprint.
I will describe these three activities in detail below.
What is a Sprint Goal?
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.
What Is a 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).
While average time to complete a task can usually be tracking with a good time-tracking tool, you can also use several other estimation methods to do agile capacity planning and determine your team's velocity.
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 estimate 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
So, you've done all your necessary preparations and you've finally made it to the sprint planning meeting. 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.
