Raise your hand if this scenario sounds familiar—you’re sitting in a never ending sprint planning meeting that has once again gone off the rails, you leave feeling unsure of what you’ve accomplished, and you promptly forget about it until the dreaded moment when the meeting pops up on your calendar next?
If I'm reading your mind about the challenges of running a successful sprint planning meeting, then this article is for you!
I’m here to tell you that it doesn’t have to be this way. In this article, I’ll offer up some helpful tips to make your next agile sprint planning meeting more efficient, effective, and less dreadful for the whole team.
We’ll cover:
- What is a Sprint Planning Meeting?
- Who is Involved in the Sprint Planning Meeting?
- Why Should You Run a Sprint Planning Meeting?
- How Do You Run a Sprint Planning Meeting?
- Sprint Planning Meeting Agenda Template
After reading this article, you’ll be armed with more information to make a bigger impact in less time at the next sprint planning meeting that you run.
What Is A Sprint Planning Meeting?
Sprint planning meetings are one of the most widely adopted agile Scrum ceremonies. In the Scrum framework, a sprint is a term used to denote when work begins and ends. Sprints may range from one to several weeks in duration, although two-week sprints tend to be the most common.
The sprint planning meeting should answer the following questions: What increments can be delivered in the next sprint? And how will we accomplish that work?
To put it simply, the sprint planning meeting should provide structure, set expectations, and define the backlog for the upcoming sprint.
What is Sprint Planning?
We’ve been talking about a sprint planning meeting, but what is sprint planning exactly?
Sprint planning is the process of:
- Reviewing the available backlog of work
- Scheduling the work that your team will complete in the next sprint based on the amount of time that work is expected to take and team member availability
When Should the Sprint Planning Meeting Happen?
You’ll need to time your sprint planning meetings to coincide with the start of your sprints, although there are some nuances to consider.
Too close to the start of the sprint, and you waste a precious day of working time on planning efforts. Too far away from the sprint start, and your team won’t have the information they need to plan effectively. For example, they may not know the outcomes from the previous sprint and/or team availability during the next sprint.
For these reasons, it’s best to hold your sprint planning meeting a day or two before the start of the next sprint. Pro tip: you might want to avoid Fridays if that’s a day that people tend to take off or if you prefer a lighter meeting day at the end of the week.
Who Is Involved In The Sprint Planning Meeting?
Sprint planning meetings are a collaborative effort and involve several stakeholders. Let’s break down the roles of each meeting participant.
The Scrum Master
The Scrum master facilitates the sprint planning meeting, including ensuring that meeting rooms are booked, supplies are available, people are prepared, and video conferencing and other connectivity details are ready to go.
In terms of scheduling, the Scrum master should be timeboxing the meeting based on the length of the sprint. For example, if the team is working in two-week sprints, the sprint planning meeting should not exceed 2-4 hours (although a shorter meeting is preferred, if possible!)
The Scrum master must manage time appropriately to make sure that the team aligns on the sprint goal before the meeting concludes.
The Product Owner
The product owner is responsible for preparing the backlog in advance of the sprint planning meeting.
They must clarify details on each product backlog item and be able to answer questions around use cases and/or acceptance criteria. Sprint planning is arguably the most important agile ceremony for a product owner and requires ample preparation time.
The Development Team
Obviously, the people doing the work will need to be in the sprint planning meeting. Designers, developers, test engineers—anyone who will contribute to the work product—needs to actively participate.
Following the meeting, they should have a solid understanding of what’s expected of them and what is the priority to work on over the next sprint.
Keep in mind that teams get better at sprint planning with time. If a team is newly formed (or new to the agile methodology), they will have less certainty about how much the team can realistically accomplish within each sprint. As the team continues to work together and gains greater experience with agile, forecasting will get better.
Bottom line: agile is about continuous improvement, so give yourself some grace if your first sprint planning meeting did not go as well as you had hoped!
Why Should You Run a Sprint Planning Meeting?
Why run a sprint planning meeting? Sprint planning meetings help teams understand what they should be working on and, more importantly, why.
Involving the entire team in these meetings promotes collaboration—the team becomes more efficient at working together and feels more confident about what they’re supposed to deliver.
Below, we’ll talk about a few of the biggest benefits of sprint planning meetings.
1. Better Define Your Goals
If you are a Scrum master (or in a similar digital project manager role) on a team that is delivering development work and using agile methodologies, you should be running a sprint planning meeting.
Successful sprint planning meetings help set your team up for success because they allow everyone to understand exactly what the goal is for each sprint of work.
You’ll define two major things during sprint planning:
A sprint goal
This is a short (1-2 sentence) description of what the team plans to complete over the course of the sprint. The team writes it together and publishes it so that people can refer to it at any time.
The sprint goal is also a quick and easy statement for stakeholders to read and understand what the team is working on, without having to go into the weeds of the backlog.
The sprint goal is the measuring stick used at the end of the sprint that helps answer the question: Was this last sprint successful?
One example of a sprint goal could be: Build feature X to coincide with the holiday launch (signaling that a feature delivery by a certain milestone is the main sprint goal).
A sprint backlog
This is a list of the product backlog items that the team selects and commits to working on during the sprint. It also includes the necessary tasks required to deliver the work and an estimate of how long each task should take.
If you need extra help with this, the team at Mountain Goat Software has a video course on Scrum foundations and explains how the sprint backlog ought to come together during sprint planning.
It’s easy for sprints to go off the rails without a shared understanding of what should be accomplished. The sprint planning meeting is your means to an end to get there.
2. Promote Team Alignment and Buy-In
Sprint planning meetings demand a collaborative, team effort to arrive at the required outputs. The team, not an overpowering product owner or an outside stakeholder, decides how much gets done during a sprint.
Your team members also gain a sense of empowerment by taking charge of their flow of work. They benefit from better alignment with others by having the time to talk about how their work will fit together over the next sprint.
3. Provide a Reference Point for Measuring Velocity
Sprint velocity is a metric that defines how much work a team can tackle during a single sprint. After a team has worked together for a bit, you can calculate average velocity by adding up the completed user story point estimations at the end of each sprint.
For example, if in Sprint 1 the team completed 25 story points, in Sprint 2 they completed 35, and in Sprint 3 they completed 30, the team velocity would be 30.
25 + 35 + 30 = 90/3 = 30
Moving forward, the entire Scrum team would know that, on average, they complete 30 story points per sprint and could use this as a guide when going through the backlog items in sprint planning.
As mentioned above, the team decides what they want to tackle each sprint, so if they want to shoot for 40 story points, and everyone agrees, the sprint backlog could add up to more story points than their velocity. The inverse could also be true.
Velocity will ebb and flow over time, but a mature agile team’s velocity will start to trend upward as they get more and more used to working together and more comfortable with the product.
The product owner should keep velocity in mind when determining how many sprints it will take to release the next version of the product.
How Do You Run A Sprint Planning Meeting?
Here is a visual aid to illustrate how the sprint planning meeting should go:
Before we discuss how to run the meeting itself, we’ll need to talk about the pre-work required. Arguably, the most important part of a sprint planning meeting is the preparation before the meeting starts.
Sprint Planning Meeting Preparation
Groom the backlog
In the weeks or days leading up to sprint planning, the product owner must ensure that any items in the backlog that could be considered for the sprint (features, bugs, optimizations, stakeholder feedback, etc.) meet the team’s definition of ready.
The product owner should review the items in the backlog to identify or remove dependencies, write test cases, list acceptance criteria, and set descriptions so that the team understands the context for each item.
It’s helpful if backlog refinement covers two sprints’ worth of work in case the team has questions about how this work will relate to future work.
Without backlog grooming, the sprint planning meeting is less efficient and more time-consuming for everyone.
Measure user stories
The product owner, with the help of the team, also needs to ensure that each user story is the right size, not too large or small, to be thoughtfully considered during sprint planning. The team will have a better idea of this the longer they work together.
Examine the team’s commitment
Take a look at the calendar to assess team availability. Are there holidays coming up? Will your lead developer be out on vacation? Come to the meeting with an understanding of how much time people will be available over the next sprint.
Establish your velocity or how you’ll measure it
This is unique to every team. If you have an average amount of work that’s typically completed in each sprint, use that as your measuring stick of how much can get done while planning the sprint.
If you’re working to establish this for a newly formed team, be sure to track how many story points are completed and accepted sprint over sprint.
Gauge your capacity
This is another measurement that’s related to team availability. If your team is not fully dedicated to one product—or might be pulled away to work on other things—be sure to take that into consideration when planning out the sprint.
Create a sprint planning meeting agenda
Create an agenda and distribute it to your team. You can save time by adapting this template of a sprint planning meeting checklist.
As part of the agenda preparation, also ensure that you’ve taken care of the necessary meeting logistics, including:
- Booking meeting rooms
- Providing any supplies
- Notifying the team in advance that the meeting is taking place
- Verifying video conferencing and other connectivity details.
The time limit for the meeting depends on the length of the team’s sprints. If you’re using two-week sprints, sprint planning should not exceed 2-4 hours (although, in my experience, a 60-90 minute meeting is sufficient.)
Now you’re ready to dive into your sprint planning meeting!
During the Sprint Planning Meeting
We’ve developed a great sprint planning meeting agenda for the sprint planning process. In this section, we’ll dive into the agenda in a bit more detail and show you what the steps look like:
Check-in with the team
Don’t underestimate the importance of small talk to lighten the mood and get the team engaged—especially in remote environments. You could even consider starting with a standard icebreaker question to get the creative juices flowing.
Review upcoming priorities
Once the team is comfortable and ready to go, pull up the product backlog and review upcoming issues one-by-one. As you go through each item in the backlog, the team will need to discuss and ask questions. The product owner is responsible for clarifying the details behind each item in the backlog.
Estimate priorities
If items are not estimated already, estimate them to get a sense of how many can be selected for a sprint. You could use a planning poker game to streamline this process.
Review roadmap progress
Chances are the Scrum master, product owner, or another team member has received updates from outside stakeholders since the last time the team planned a sprint. It’s important to review any new insights that affect the roadmap to set the context for what the upcoming sprint will look like.
Review projected velocity
Address vacations, holidays, and competing projects so the team has an accurate idea of how much time they’ll be able to dedicate to the current sprint. It sounds basic, but this reality check is super important so the team doesn’t overestimate how much time they have available.
Then, make sure the team is aware of its velocity as they select user stories to attack over the next sprint. It’s always easier to have a velocity metric to work toward instead of relying on a gut feeling.
Select sprint backlog issues
Start at the top of the backlog and work collaboratively to choose items to tackle this sprint. Let the team review each item to see who will own what. The goal is to leave the meeting with an understanding of exactly what each person is working on and how they are going to accomplish the work.
Define sprint goal
Once you’ve selected the issues for the sprint, make sure that these issues align with the intended outcome for the sprint. Make any necessary adjustments to the sprint backlog.
Confirm alignment
The Scrum master reviews the proposed plan against team velocity and team capacity and for alignment with the product vision. Most importantly, the Scrum master ensures that the team agrees with the plan. This means asking every person if they’re comfortable with it.
Hopefully, everyone is aligned and feels confident they can deliver that chunk of work based on what they know today. Inevitably, things will change, but if the team feels confident in accomplishing the sprint goal, your work there is done (for now).
After the Sprint Planning Meeting
Get back to work
Let the team work! Everyone should have plenty to do following sprint planning. The team may be eager to dive into the details or start collaborating on some user stories together. You’ll be able to check in with the team at the daily standup (aka the daily Scrum meeting) tomorrow.
Sprint Planning Meeting Agenda Template
Get your template here (you’ll need to be a member) and use the insights in this article to fill it out and get the checklist ready for use in your next sprint planning meeting.
You’ll also get a handy sprint planning checklist to help you prepare for the meeting (whatever your role), as well as an email template you can send to stakeholders and other invitees.
What Do You Think?
The sprint planning meeting can seem overwhelming, but with sufficient preparation and a team that is willing to tackle a sprint together, sprint planning becomes the most effective element in the Scrum ceremony arsenal.
If you’re still asking yourself if your team is ready for one of these, keep in mind that you should run a sprint planning meeting if you have a backlog of work, are part of an agile team that is dedicated to building a product, and are already using some agile processes to get the work done.
I’m curious to know if anyone else has tips up their sleeve to make the sprint planning meeting even better! Leave a comment below, and let’s learn from one another.
For more on the other Scrum events, read about sprint retrospectives and sprint reviews, or subscribe to The Digital Project Manager’s newsletter.
7 Comments