Have you ever sat in a sprint planning meeting that seems to drag on and ultimately doesn’t result in anything much—except for dread of the next one? I have. And I want to change that.
The sprint planning meeting is an important ceremony for teams to conduct in order to create good work.
In this article, I am going to unpack this particular meeting and offer up some helpful tips to make your next agile sprint planning meeting more efficient, effective, and less dreadful.
- What a sprint planning meeting is
- Why you should run a sprint planning meeting
- How to run a sprint planning meeting
- A sprint planning template download
After going through this, you will be armed with more information to make a bigger impact in less time at the next sprint planning meeting that you run. Let’s dive in.
What Is A Sprint Planning Meeting?
A sprint planning meeting is one of the Scrum ceremonies widely adopted by teams who utilize sprints to mark when work “begins” and “ends.” It is designed to answer the questions, What can be delivered in this 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.
There are several people involved in these meetings, and it is a very collaborative effort. Let’s break down what each role does.
The ScrumMaster facilitates the sprint planning meeting and ensures that meeting rooms are booked, supplies are available, people are prepared, and all video conferencing and other connectivity details are ready to go. In terms of scheduling, the ScrumMaster should be timeboxing this meeting according to the length of the sprint. For example, if the team is working in 2 week sprints, the sprint planning meeting should between 2-4 hours. The ScrumMaster must manage time appropriately to make sure that there is complete alignment on the sprint goal before the meeting wraps up.
The Product Owner
The Product Owner is responsible for ensuring that all items in the backlog are prepared before the meeting. They must clarify details on each backlog item and be a resource to the team when asking questions around use case or acceptance criteria. This is arguably the most important meeting for a Product Owner & one they must set aside plenty of time for to prepare.
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 be in attendance and actively participate in this meeting so that they can walk away with a solid understanding of what’s expected of them and what is 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), there may not be as much shared understanding on how much can get done within each sprint. Later, we’ll talk about calculating velocity. Just keep in mind that mature teams tend to do better at this. There’s an element of constant improvement with agile, 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? Because it is a great opportunity to get the whole team together and collaborate to establish what everyone is responsible for over the next sprint! From a personal perspective it was difficult for our team to identify what exactly they were working on each sprint, and – more importantly why – before we adopted this agile practice. Since then, it’s been much easier for our team to work together and feel more confident about what we’re supposed to deliver.
A team that knows its exact goals is a happy team. According to Christina Hartman, PMP, PMI-ACP, the basic benefits of sprint planning include:
- Collaboration and team building
- Common understanding of the product
- Task discovery
- Task sign Up
- Task prioritization
- Task estimation
- Knowledge and skill set improvement
- Different perspectives
- Promotes Just In Time (JIT) planning
Below, we’ll talk about just a few of the biggest benefits of sprint planning meetings.
1. Brings Definition To Your Goals
If you are a ScrumMaster (or similar DPM role) on a team that is delivering development work and utilizing agile methodologies, you should be running a sprint planning meeting. These meetings help set your team up for success because it allows 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 is going to complete over the course of the sprint. The team writes it together and publishes it so that people can refer back 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 each 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 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 all the necessary tasks required to deliver the work. Each task should also be estimated. The great team at Mountain Goat Software has a video course on scrum foundations & 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. Brings Alignment And Buy-In From Your Team
Keep in mind that it is a collaborative, team effort to arrive at the outputs you’ll have by the end of a sprint planning meeting. The team decides how much gets done during a sprint, not an overpowering Product Owner or an outside stakeholder. Your team members gain a sense of empowerment by taking charge of their flow of work. They also benefit from better alignment with others by having the time to talk about how their work will fit together over the next sprint.
3. Provides A Reference Point For Measuring Velocity
You should also run a sprint planning meeting if you know how much your team can accomplish during a sprint. This is commonly referred to as velocity and is established after a team has been working together for a bit. According to Scrum Inc.,
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum.
It’s calculated at the end of a sprint by adding up all of the completed user story point estimations and averaged out over the course of several sprints.
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 velocity would be 30. 25 + 35 + 30 = 90/3 = 30.
Moving forward, the 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 bite off 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 on the product. Velocity is a key number for the Product Owner to keep in mind as they work to figure out how many sprints it will take to release the next version of the product.
Not sure where to begin?
Becoming a confident, successful project manager is no simple feat—if you’re looking for a good place to start, our online course in Mastering Digital Project Management will light the way. In this 7-week course, you’ll gain access to relevant, practical expertise that will help you lead happy teams and deliver high-value projects in the digital world.
Whether you are formally trained as a project manager or an account manager who has been cast into the role, it’s your job—and privilege—to become a master in the art of managing projects. Our course will equip you with the fundamentals that will help you meet the daily challenges of project management, evolving as a professional in the big, wild world of Digital Project Management.
How Do You Run a Sprint Planning Meeting?
Here is a visual aid to illustrate how this meeting should go:
Before we get into the steps of this meeting, some preliminary work needs to get done. Arguably the most important part of a sprint planning meeting is the preparation that must be done before the meeting starts.
Sprint Planning Meeting Prep
In the weeks or days leading up to sprint planning, the Product Owner must ensure that all items in the backlog that could be considered for the sprint (features, bugs, optimizations, stakeholder feedback, etc.) meet the team’s definition of ready. This means that items are organized, dependencies identified or removed, test cases are written, acceptance criteria is listed, and all descriptions are set. Without this prep work, 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 for everyone’s availability. Are there holidays coming up? Will your lead dev be out on vacation? Have a good idea 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 the pieces above. 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 sprint planning template.
One other thing to consider is how much time to schedule for the sprint planning meeting. As mentioned above, the length of sprint planning is typically a function of how long the team’s sprints are. As Mitch Lacey & Associates explain, “for a one month or four-week sprint this meeting should last eight hours. For a two-week sprint, plan for about four hours. As a general rule of thumb, multiply the number of weeks in your sprint by two hours to get your total sprint planning meeting length.”
Assuming all of that is taken care of, you are ready to dive into your sprint planning meeting!
Sprint Planning Meeting Agenda Template
This content is exclusive to DPM Members!
DPM Membership is currently restricted to a limited number of Beta Members, but we're rolling out Membership for everyone in July.
Put your name on the waitlist to learn more about Membership perks and be notified when Membership goes live!
During The Sprint Planning Meeting
Leading Agile has a great sprint planning meeting agenda for the sprint planning process. We dive into a bit more detail and show you what the steps look like:
Remind the team of the big picture or goal
It’s critical to set the stage for the team and the meeting itself by articulating aspirations, goals, or visions for the project. Everyone is working hard for a reason.
Discuss any new information that may impact the plan
Chances are, the ScrumMaster, Product Owner, or other team member has received updates from outside stakeholders since the last time the team planned a sprint. It’s important to review any new information from the market or customers that help to set context for what the upcoming sprint will look like.
Present the velocity to be used for this release
Make sure the team is aware of current velocity so they can be informed as they select stories to attack over the next sprint. It’s always easier to have this in the back of your head instead of relying on a gut feeling.
Confirm team capacity
Vacations, holidays, competing projects. All of these should be addressed so the team has an accurate idea of how much dedication they’ll have to this sprint.
Confirm any currently known issues and concerns and record as appropriate
The team likely has feedback on things they’ve run into when completing the past sprint. These could be reasons why they couldn’t complete some stories or a new update that threw a wrench in the plan. Stuff happens! Be sure to address these with the team at large.
Review the definition of DONE and make any appropriate updates based on technology, skill, or team member changes since the last sprint
The only way someone knows if something is complete is if there is a clear description of what “done” means. Give the team what they need to grade their completion! Also, team members may have been moved around or added since the last sprint. Address this and make changes accordingly.
Present product backlog items to consider for the sprint backlog
Now the team can review the proposed backlog. These were prepared by the Product Owner and organized by value. It should be roughly the size of two sprint’s worth of work, just in case the team has questions about how this work will relate to future work.
Determine the needs, sign up for work, and estimate the work owned
This is where the true collaboration and negotiation comes in. Let the team review each item to see who will own what. If items are not estimated already, estimate them to get a sense of how many can be selected for a sprint. As a ScrumMaster, make sure you have an eye on the clock.
Product Owner answers clarifying questions and elaborates acceptance criteria
As you go through each item in the backlog, the team will need to discuss and ask questions. The Product Owner is the one who should serve as a resource to the team. The goal is to identify exactly what each person is working on and how they are going to get the work done.
Confirm any new issues and concerns raised during meeting and record
If anything else came up during sprint planning that wasn’t already on the radar, find a space to record those and identify action items.
Confirm any assumptions or dependencies discovered during planning and record
Similarly, the ScrumMaster should be noting any other related impacts that may arise from the sprint plan getting put together. This could have a result on a later sprint.
ScrumMaster calls for a group consensus on the plan
Once the sprint backlog has been identified, the ScrumMaster asks the whole group if they are aligned on the plan. Review it against your current velocity and capacity. Review it against the overall product vision. Ask every person if they’re comfortable with it.
Team and Product Owner signal if this is the best plan they can make given what they know right now
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).
Get back to work
Let the team work! Everyone should have plenty to work on after sprint planning and might want to go back to their stations to dive into more details or start collaborating on some user stories together. You’ll be able to check in with the team at the daily standup tomorrow.
What Do You Think?
The sprint planning meeting can seem very overwhelming, but if enough prep is done and the team is ready to tackle a sprint together, it is 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 a part of an agile team that is dedicated to building a product, and are already utilizing 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.