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:
- “How do we know which tasks we should take forward?”
- “Are we planning too much or too little work?”
- “Does our Sprint Planning support our Sprint Goal?”
- “Who gets to choose what we work on? Is it just the Product Owner or do developers get a say too?”
- “How do I facilitate a Sprint Planning meeting?”
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
What is Sprint Planning?
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:
- A Sprint Goal: The Sprint Goal comprises one or two short sentences that set the overall objective for the Sprint. The goal is to deliver a working product (update) with improved functionality that solves a specific problem for customers (also referred to as an increment).
- The Sprint Backlog: The Sprint Backlog is a list of work items selected from the Product Backlog that will fulfil the Sprint Goal when completed.
Note: Some Scrum teams refer to these combined artifacts as the “Sprint Plan.”
What is the value of Sprint Planning?
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.
When does Sprint Planning take place?
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!
Who attends Sprint Planning?
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:
- Scrum Master: Potentially facilitate the meeting, safeguard time, coach team members on how to participate in Sprint Planning, and answer any questions about Agile principles.
- Development team members: Calculate team capacity for the upcoming Sprint and decide its scope by building the Sprint Backlog. The development team may also help the Product Owner refine the Product Backlog before the meeting starts.
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.
How to run a Sprint Planning meeting [5 Step Process]
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.
1. Prepare for Sprint Planning
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.
Draft a preliminary Sprint Goal
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:
- “Learn about the right user interaction for the registration feature.”
- “Make the reporting feature available to the users.”
- “Create a paper prototype of the user registration feature to test our user interaction ideas.”
Backlog refinement: Preparing the Product Backlog
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.
Calculate capacity, velocity, and other relevant metrics
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.
2. Close the previous Sprint
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.
🙋🏾 Facilitator prompts:
- What insights from the last Sprint Retrospective did I miss?
- How do we feel about the unfinished work from the previous Sprint?
- What was the most interesting stakeholder remark during the Sprint Review? What action do we need to take based on that?
3. Decide what to work on
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.
Set a Sprint Goal
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.
Select Product Backlog items to meet the Sprint Goal
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.
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.
- What’s the simplest way to achieve this Sprint Goal?
- What valuable opportunities or options do we exclude with this tentative Sprint Goal?
- What tasks from the Product Backlog can help us achieve this Sprint Goal?
- How confident are you to achieve the Sprint Goal? Do we have enough or too many tasks? If the team is not sure, ask them to imagine what could go wrong (a pre-mortem question).
- Will the tasks we have selected—if shipped—make up a piece of working software at the end of the Sprint?
4. Figure out how to do the work
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:
- Break down every item.
- Turn only high-priority items into tasks.
- Estimate if all working items fit one Sprint, without any task breakdowns.
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:
- The Sprint Backlog is flexible. You can make changes to the Sprint Backlog—add, change, or remove items—if those help you achieve the Sprint Goal.
- The Sprint Goal is fixed. The Sprint Goal should not be changed. You should do everything you reasonably can to achieve it.
- The perfect plan doesn’t exist. The extra effort necessary to develop a flawless plan—which is impossible anyway—is better spent on your Sprint while making adjustments along the way.
- The perfect task size exists. Tasks shouldn’t take longer than one day. Small tasks that are a day’s work or less increase productivity because they make results visible and frequent.
- The team’s capacity isn’t a target. A velocity of, say, 100 story points doesn’t mean you need to max out every Sprint to that number or continuously increase it. Buffers reduce mistakes, and you can always pull in more items along the way—or finish your Sprint early if you’re practising Scrumban.
Maarten Dalmijn explains how most of these principles reinforce each other:
Imagine your team believes everything added to the Sprint is fixed and… the Sprint is only a success if all Sprint Backlog items are finished. As a consequence, the team will waste more time in Sprint Planning to try and come up with an impeccable Sprint Plan.
🙋🏽 Facilitator prompts:
- Which Sprint Backlog item are you most concerned about and why?
- Are they any items could we drop and still achieve the Sprint Goal?
- Do any team members expect to be over or under capacity this Sprint? Should we re-arrange any work to adjust for this imbalance?
5. Settle on the Sprint Goal and scope
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.
🙋🏻 Facilitator prompts:
- What’s the biggest assumption or unknown in our Sprint Plan?
- “If anyone has objections to the Sprint Goal, speak now or hold your peace until the next Sprint.” 👰🏽
Sprint Planning: Your gateway to a successful Sprint
To ensure your directions are accurate, refer to this checklist, which summarizes everything you need to cover for effective Sprint Planning:
- The Product Backlog looks good for the big day: it is refined and prioritized for Sprint Planning.
- Takeaways from the previous Sprint Review and Sprint Retrospective are at hand, ready to become action items for this Sprint.
- Strictly timebox Sprint Planning in proportion to the length of your Sprint.
- Consider the team’s capacity for the upcoming Sprint in creating the Sprint Goal and Backlog.
- The development team knows they’re empowered to change the Sprint Backlog during the Sprint, but not the Sprint Goal.
- The development team determines the final Sprint Backlog, not your directives or stakeholder pressure.
- End Sprint Planning with a crisp and meaningful Sprint Goal that every team member understands.
If you follow these seven steps and adopt our discussed practices, Sprint Planning mastery and valuable Sprints await you.