The Product Owner’s Guide to Better Sprint Planning

Effective Sprint Planning is the first step of a successful Sprint. But it can also be one of the hardest agile meetings for Scrum teams to get right.

In a Sprint Planning meeting you may find yourself asking:

You can avoid all this confusion through ample preparation.

In this resource, we’ll support you to go into your Sprint Planning meeting with a clear purpose and a set of processes that set every Sprint up for success.

Table of contents

During Sprint Planning, Scrum teams decide which are the most valuable Product Backlog items to deliver in the next Sprint. The Product Owner and development team do this together, by deciding on an overarching Sprint Goal and selecting relevant backlog items that help them achieve that objective.

Sprint Planning helps teams identify two key things:

Note: Some Scrum teams refer to these combined artifacts as the “Sprint Plan.”

Sprint Planning ensures teams have enough direction and structure to know what to work on next. The event eliminates the need for long-term plans that are often inflexible, unrealistic, or become obsolete due to changing customer and business priorities.

Teams increase the chances of making a valuable product improvement during the Sprint when tasks are connected to a meaningful Sprint Goal during Sprint Planning.

Doing Sprint Planning also reduces the risk of running into issues mid-Sprint as you’ve already created a shared understanding and plan on how to accomplish the Sprint Goal.

Sprint Planning takes place on the first day of a new Sprint. It always comes after the Sprint Review and Sprint Retrospective from the previous Sprint. This is so you can include outcomes from those meetings in your plans.

You can timebox Sprint Planning sessions, meaning you set a strict time limit on the meeting’s duration, determined by the length of your Sprint. The Scrum framework suggests you reserve eight hours on your calendar if you’re running one-month Sprints.

By that logic, Scrum teams that run two-week Sprints should budget for a four-hour Sprint Planning meeting.

In reality, most experienced Scrum practitioners – including Product Owner Maarten Dalmijn – recommend doing the meeting in half that time or less if you can. A shorter meeting time prevents prolonged discussions about task details and estimates that don’t add value or improve the chances of your plan’s success.

Besides, would you want to attend a four-hour meeting? Didn’t think so!

The entire Scrum team joins Sprint Planning. The Product Owner, Scrum Master, and the developers.

Here are the primary Sprint Planning responsibilities of each team member:

We recommend that a Scrum Master, rather than a Product Owner, facilitates Sprint Planning Events – especially when you’re starting out. A Scrum Master can ensure all participants follow Agile principles and give developers the freedom to decide the scope of the Sprint and the tasks they will take to fulfil the Sprint Goal.

A Product Owner also has enough work to do before and during Sprint Planning, even when they’re not leading the meeting. It’s usually a welcome relief for them when someone else facilitates the event.

The one prerequisite for this ideal approach is that your agile team or organization actually has a Scrum Master, which isn’t always the case.

Let’s run through the five phases of Sprint Planning most Scrum Masters, Product Owners, and Agile coaches go through when they run this Scrum ceremony.

Preparation for Sprint Planning largely falls on the Product Owner.

The Product Owner needs to have the Product Backlog ready, along with a draft Sprint Goal, and (optionally) up-to-date agile metrics like velocity and throughput that help teams check they’ve assigned the right amount of work.

During the Sprint Planning meeting, teams finalize and agree on the Sprint Goal together. However, the Product Owner should come to the event with a draft Sprint Goal prepared. This prevents the task of “finding a goal” taking up most of the meeting.

The draft Sprint Goal comes in handy in helping the Product Owner decide which Product Backlog items to refine and prioritize before the meeting based on their relevance to the objective.

Author and agile product management expert Roam Pichler gives some examples of effective Sprint Goals here:

When Sprint Planning starts, the Product Backlog should have the items of the highest priority and relevance to the draft Sprint Goal at its top.

These items should include acceptance criteria, which validate if a specific item is truly completed. You may also want to create a Definition of Done for the entire selection of tasks. This sets the standards all items must meet.

As a general rule, all product backlog items should be DEEP – detailed, emergent, estimated, and prioritized.

Scrum expert and author Mike Cohn recommends having two Sprints worth of Product Backlog items ready for Sprint Planning. That rule of thumb gives the development team sufficient work to choose from, but not too much for the Product Owner to prepare.

Some Scrum teams schedule backlog refinement as a separate meeting before Sprint Planning. In a backlog refinement meeting, teams may refine items together by adding detailed steps involved in completing each task and estimating their sizes using story points, agile estimation techniques, or a product like Sprint Poker.

Sprint Poker is an effective, fast, and fun way for agile teams to estimate user stories in the backlog.

The development team needs to figure out their capacity for the upcoming Sprint so they know how much work they can plan. Factors like vacations, holidays, illness, training, resignations, and new hires will affect the amount of work the team can do and the Sprint’s potential scope.

Many teams also look at their historical performance to predict how much work they can take on in the future. If your team does this, the Product Owner needs to calculate the metrics you’re using for such forecasts. For example, velocity, cycle time, or throughput.

Sprint Planning is the Scrum ceremony that starts a new Sprint. So before Sprint Planning you need to close your last Sprint.

Make sure to include action items from the last Sprint Review and Retrospective in your plans, and address any unfinished work from the previous Sprint.

Incorporating insights from previous Sprints as part of your Sprint Planning routine is continuous improvement in action. You’ll integrate stakeholder feedback, process improvements from retrospectives, and make tweaks to your product development process every Sprint.

Even if such changes are small individually, they create significant improvements over time.

Take some time to also include unfinished work from your previous Sprint in the next one. Maarten Dalmijn recommends not spending time re-estimating such items but counting their full value again for this Sprint. This practice is fast and gives the team a buffer. He also suggests always completing work your team has started on unless you’ll never need it in the product.

Deciding on a Sprint Goal is the first significant order of business for your new Sprint.

The objective informs most other decisions during the meeting, like the set of product backlog items to select.

The Product Owner explains the draft Sprint Goal and why this objective will create customer value. They might also clarify how the goal serves the long-term vision and roadmap.

The other team members can now ask questions and, through such discussion, arrive at a Sprint Goal that will guide the rest of the Sprint Planning session.

The Product Owner can now briefly explain why they think the prioritized items at the top of the Product Backlog are most relevant to the Sprint Goal. The development team then asks questions and selects items they deem valuable by moving them from the Product Backlog into the Sprint Backlog.

As the team moves items into the Sprint Backlog, it’s important to keep an eye on the team’s capacity and velocity. After adjusting that number for the upcoming Sprint’s capacity, the total number of story points of the selected items should not exceed the team’s velocity.

You should divide any items that don’t fit within the length of one Sprint into smaller user stories or tasks. This is called story splitting.

If you realize new work items are needed to achieve the Sprint Goal, you should either create and estimate them immediately or adjust the objective. You can also rework the Sprint Goal if you discover you can’t meet it with your current capacity.

Now it’s time to discuss how you’ll complete the items you’ve selected.

The purpose isn’t to have an exact breakdown of each item but to have considered the biggest unknowns, risks, dependencies, and complexities with the entire team.

Mike Cohn explains that there are three approaches to breaking down user stories and other work items into tasks during Sprint Planning:

Note that some teams may be able to skip this step if they’ve already broken down their product backlog items into specific tasks with story point values during backlog refinement.

Here are five essential principles to keep in mind during this phase of Sprint Planning:

Maarten Dalmijn explains how most of these principles reinforce each other:

Now that you have a much clearer picture of the upcoming Sprint, do a final sense-check on the Sprint Goal and see if you need to tweak it.

Ask everyone if they have confidence in the Sprint Goal and the Sprint Backlog. Take this opportunity to remind everyone that you’ll measure success against the Sprint Goal, not individual performance or tasks.

Your aim with this last check is not to start from scratch, but to rephrase or resize the Sprint Goal—ideally just slightly—based on any final feedback that comes up here.

The outcomes of Sprint Planning – the Sprint Goal and your Sprint Backlog – are guideposts during your current Sprint. Try checking in on them periodically and during the Daily Scrum.

To ensure your directions are accurate, refer to this checklist, which summarizes everything you need to cover for effective Sprint Planning:

If you follow these seven steps and adopt our discussed practices, Sprint Planning mastery and valuable Sprints await you.