Your step-by-step guide to running a Sprint Planning meeting effectively

At the core of the most popular of Agile methodologies, Scrum, lies the Sprint. Sprints are where the work happens, where the team delivers value for the customer, and where the team gathers feedback to make the next Sprint even better.

That’s why Sprint Planning is so important. It sets the team up with everything they’ll need to perform optimally during the Sprint. But it may not be what you think it is. Sprint Planning isn’t about delegating tasks and nailing down every second of the Sprint ahead.

We’ll cover all the basics of what you need to know about this crucial Scrum ceremony. We’ll teach you what Sprint Planning entails, how to prepare properly for your meeting, what to include on the agenda, how you can expect the planning process to evolve from Sprint to Sprint, and more.

Whether you’re a Product Owner, Scrum Master, or Developer this article will help explain how the whole Scrum Team can plan Sprints more effectively.

What is a Sprint Planning meeting?

Teams that follow Scrum, a type of Agile framework, work in timeboxed iterations called Sprints. These cycles make large, complex projects more manageable and last anywhere from one to four weeks, with two weeks being the most popular length.

Sprint Planning is the process of laying down the groundwork for the Sprint. And since there are multiple Sprints throughout the lifetime of a single project, Sprint Planning is a recurring meeting, which happens at the start of every Sprint.

During the meeting, the entire Scrum Team -- which consists of the Product Owner, Scrum Master, and Developers -- collaborate to decide on a goal for the upcoming Sprint and which items they’ll pull from the Product Backlog to achieve that goal.

It’s one of the four Scrum ceremonies along with Daily Scrum, Sprint Review, and Retroactive.

What are the roles in Sprint Planning?

As mentioned above, Sprint Planning is a collaborative event that includes members of all three roles in the Scrum Team. Let’s break down what those roles are.

1. The Product Owner acts as a liaison between the business side and the development side. They’re accountable for representing the stakeholders and managing the product backlog to align the business objectives with the the developers' work. The Product Owner ensures that the entire Scrum Team is delivering as much value as possible.

1. The Scrum Master sees to it that the Scrum Team is working as effectively as they can. They do this is by implementing Scrum. They coach the Developers, the Product Owner, and even the entire organization so that everyone has a firm grasp on Scrum theory and practice.

1. The Developers, or Development Team Members, are self-organizing and cross-functional individuals whose responsibility is to deliver value through the Sprint. They execute the plan. “Developers” doesn’t just refer to engineers. A Developer can be a designer, a writer, a programmer, and more.

How to prep for the Sprint Planning meeting

Preparation is everything. When it comes to planning in Agile, there are always layers. Here’s what we mean: It’s not enough to plan for the Sprint. You must also prep for the actual Sprint Planning meeting.

What does that look like? In a nutshell, here’s what needs to be done before the meeting.

1. Refine the Product Backlog.

This process is aptly named Product Backlog refinement. More on this below.

2. Check the team’s availability.

Are there any upcoming holidays? Are any team members going on vacation? Is there anything that might take away from the team’s capacity and affect the Sprint? What about their other projects they're working on? Tip: For a no-fuss way to gain insight to your team’s calendar, check out Clockwise for Teams.

3. Create and distribute the meeting agenda.

Team members should be able to review it beforehand.

4. Establishing a start and end time for the meeting.

We’ll cover how to estimate meeting duration below.

Product backlog refinement

Prior to the Spring Planning meeting, the Product Owner reexamines the Product Backlog and makes adjustments where necessary. This process is officially called product backlog refinement (formerly called backlog grooming).

Think of the Product Backlog as a master to-do list of all of the features, updates, and other deliverables for this particular project. Most commonly, teams will list these user stories, which are informal descriptions (typically one sentence in length).

It’s the Product Owner’s responsibility to go through this master list before every Sprint Planning meeting. They ensure all items are still relevant (removing items if necessary). They list items by order of priority. And they ensure that the items at the top are ready to be pulled into the next Sprint. By ‘ready,’ we’re referring to the team’s “definition of ready,” which is the criteria that determine whether the team has all the information they need to get started on the given item. The Product Owner must also define the acceptance criteria for each user story, which we’ll discuss in further detail below.

Though the Product Owner is accountable for Product Backlog refinement, they don’t have to make it a solo process. In fact, the Product Owner should involve other members of the team for additional insight. The team may refine the backlog even further during the Sprint Planning meeting itself.

Sprint Planning meeting duration

The Scrum Master is responsible for timeboxing the Sprint Planning meeting. Setting a time limit will encourage the team to stay focused.

So, how much time should you dedicate to Sprint Planning? Dave West, CEO of Scrum.org recommends setting aside two hours per week of Sprint. That means if your Sprint is two weeks long, plan for four hours tops.

If it takes less than the allotted time to craft the Sprint Backlog, that’s fine too. Just be sure that everyone reaches a consensus and feels confident about the game plan.

Sprint Planning agenda

1. The Product Owner presents the objective for the Sprint.

Though the final Sprint Goal is a product of the efforts of the whole Scrum Team, the Product Owner should come prepared with an initial objective. What will be the objective of the Sprint and how does that add to the overall big picture of the project? This is important because it explains why this Sprint and everyone's work in it are important.

2. The Product Owner proposes items for the next Sprint.

After defining the objective, the Product Owner goes over which backlog items will best support that objective — what will become the Sprint Backlog (after discussion and negotiation with the rest of the team, of course). Ideally, the Product Owner will have prepared two sprints’ worth of product backlog items.

3. The Product Owner goes over acceptance criteria.

Now it’s time for the Product Owner to break down the requirements of each user story, in other words, the acceptance criteria. What are the specifics regarding functionality, from the user’s point of view? The acceptance criteria should eliminate any ambiguity surrounding a user story, so that the team can move forward with a clear picture of what they’re creating in the upcoming Sprint.

4. The Developers provide their feedback and ask the Product Owner questions.

Here’s a mini Agile refresh for you: The first Agile value emphasizes “individuals and interactions.” Thus, it’s so important that the Sprint Planning meeting isn’t an unloading of orders. At its best, Scrum empowers every team member to play an active part in Sprint Planning.

5. Sizing and other adjustments are made to backlog items.

This is a team effort that involves the Product Owner and the Developers. Are there dependencies that haven’t been identified? Are any of the proposed items too large to fit into the next Sprint? Can it be broken down? This step is where story points come into play — another reason why it’s helpful to estimate story points through a process called planning poker. Story points are numbers that assign value to the amount of effort that a user story will require. They help the team gauge their work.

6. Review team capacity.

Team capacity is the total hours that the team can dedicate to working in the upcoming Sprint. Calculate this figure by adding up each person’s available hours, taking into account any time off.

As the team negotiates, they take items off the product backlog and transfer them onto the Sprint Backlog. By the end of the meeting, the Scrum Team will have three things: a clear Sprint Goal, the Sprint Backlog, and a plan for how they’ll get started.

First Sprint Planning meeting

If the Scrum Team has never worked together before, you can expect the first Sprint Planning meeting to play out a little differently than the subsequent ones. That’s because there’s no performance history to refer back to.

After two or three Sprints, you’ll be able to better estimate your team’s velocity (the amount of work the team can accomplish in one Sprint).

“Your first agile sprint is a baseline and getting everything ‘right’ isn’t as important as getting the team to understand the general spirit of agile. The iterations are short so the team should be able to quickly gather feedback and continue to adapt and improve over time,” writes Yvette Francino, Agile Consultant and Certified Scrum Master.

Why Sprint Planning matters

When done effectively, Sprint Planning upholds what the Agile approach stands for. With that said, let’s cover the four values of Agile, as laid out by the people who created it.

1. “Individuals and interactions over processes and tools”
2. “Working software over comprehensive documentation”
3. “Customer collaboration over contract negotiation”
4. “Responding to change over following a plan”

Sprint Planning embodies these key values by providing the time and space to:

● Collaborate on deciding what will be accomplished in the next Sprint (Value #1)

● Focus more on the Sprint Goal than the minutiae of the day-to-day (Value #2)

● Involve the customer through the Product Owner’s presence (Value #3)

● Encourage evolution by feeding what was learned from previous Sprints back into the plan for the next Sprint (Value #4)

Moving forward

The goal is to deliver value with every iteration, which in this case, means every Sprint. However, don’t lose sight of another important aspect of Scrum: the fact that it’s an adaptive process. It may not be perfect in the beginning, but as long as the team is communicative and empowered, the process will get better Sprint by Sprint. Continue to read the terrain, stepping back every now and then for the big picture, and your team will succeed!

‍