Sprint Planning Meeting: Simple How To Guide & Template
Raise your hand if this sounds familiar—you’re sitting in a never ending sprint planning meeting, 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? 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 and effective, and less dreadful for the whole team.
What Is A Sprint Planning Meeting?
A sprint planning meeting is a meeting in which the Scrum team decides what work can be delivered in the upcoming sprint and how that work will be accomplished. It's one of the five Scrum ceremonies that are part of the Scrum framework.
A sprint is a term used to denote when work begins and ends, and can range from one to several weeks in duration, but two-week sprints are most common. The sprint planning process should provide structure, set expectations, and define the backlog for the upcoming sprint.
When Should the Sprint Planning Meeting Happen?
It’s best to hold your sprint planning session a day or two before the start of the next sprint. Here's why:
- 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.
How To Run A Sprint Planning Meeting
Here is a visual aid to illustrate how the sprint planning meeting should go:
- Sprint Planning Meeting Preparation
- During The Sprint Planning Meeting
- After The Sprint Planning Meeting
Sprint Planning Meeting Preparation
Arguably, the most important part of a sprint planning meeting is the preparation before the meeting starts.
Groom the backlog (aka backlog refinement)
Prior to sprint planning, the product owner ensures that any items in the backlog that could be considered for the sprint (features, functionalities, bugs, feedback, etc.) meet the team’s definition of ready.
The product owner reviews 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.
This backlog typically exists in agile project management software or Scrum software.
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. 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. You can also use a resource management, project planning, or project scheduling tool to determine how much time each team member realistically has available for the sprint.
Create a sprint planning meeting agenda
Create an agenda and distribute it to your team (more on the specifics below). Don't forget to consider the discussions and feedback from your sprint review and/or sprint retrospective.
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 two to four hours (although, in my experience, a 60-90 minute meeting is sufficient.)
During the Sprint Planning Meeting
We’ve developed a great sprint planning meeting agenda for the sprint planning process. I’ll dive into the agenda in a bit more detail to 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 planning poker 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—this is an important step that ensures 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, how they are going to accomplish the work, and what the definition of done is for each item (i.e. how you'll know the task is complete).
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
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.
Who Is Involved In The Sprint Planning Meeting?
The Scrum master, product owner, and development are involved in sprint planning meetings.
The Scrum Master
The Scrum master facilitates the sprint planning meeting, including ensuring that meeting rooms are booked, supplies are available, and people are prepared.
The Scrum master should timebox 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 shorter 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.
The Development Team
Designers, developers, test engineers—anyone who will contribute to the work product—needs to actively participate. Following the sprint planning 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 agile project management), 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.
Why Should You Run a Sprint Planning Meeting?
You should run sprint planning meetings to 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, I’ll talk about a few of the biggest benefits of sprint planning meetings.
- Better Define Your Goals
- Promote Team Alignment and Buy-In
- Provide A Reference Point For Measuring Velocity
1. Better Define Your Goals
If you are a Scrum master 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: the sprint goal and the sprint backlog.
Sprint goal
A sprint goal is a short (one to two 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 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.
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).
Sprint backlog
The sprint backlog 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.
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 new 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.
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.
Sprint Planning Meeting Agenda [Download]
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's Next?
Looking for more tips on how to run a sprint planning meeting? Have your own you want to share? Join the conversation in Slack with 100's of other digital project managers with DPM Membership!
