What is sprint planning? What a PO should prepare

A prep checklist for the day or two before sprint planning, how to run the “what” conversation, and how to write a Sprint Goal, with templates to use straight away.

Written by Phan Lam Duy Khoi

A Product Owner should arrive at sprint planning with a proposed Sprint Goal and an ordered, ready top of the backlog. The PO does not assign tasks or dictate estimates: the Developers choose how much to take on and decide how to do it.

Sprint planning is tomorrow morning. What do you bring?

You are the PO for a tea-ordering app run by an online tea shop. Tomorrow morning the team holds sprint planning for the next two-week sprint. You open the backlog: more than forty items, some well written, some just one line saying “redo the cart”. Your manager has just messaged that they want a reorder feature before the upcoming promotion. An engineer has mentioned more than once that the payment flow has an old bug to fix.

This is an illustrative situation. Your questions are very concrete: what do I need to prepare tonight, and what do I say in the room tomorrow? Should I assign tasks to each person? Should I propose how many days each item will take?

This article answers using the Scrum Guide 2020 and a practical approach for a new PO: arrive with a proposed goal and a ready top of the backlog, then let the team decide the rest together.

Why is sprint planning confusing for new POs?

Sprint planning is the event that starts the sprint, where the whole Scrum Team plans the sprint together. It sounds simple, but new POs can stumble in three places.

Mixing up roles. Many newcomers think the PO is the person who hands out work, so they arrive with a list of who does what. According to the Scrum Guide, the Developers select the work for the sprint and decide how to do it.
A backlog that is not ready. If the top items are still vague, the meeting turns into writing requirements on the spot. Time runs out before anything is agreed.
Wanting more than the team can do. Your manager wants things, customers want things, and so do you. When the team says there is not enough time, a new PO may push harder or silently accept a plan nobody believes.

The common root is arriving without having prepared your own part. The PO's part is not splitting tasks. It is two things: why this sprint is worth doing, and which items matter most to discuss first.

What are the parts of sprint planning?

The Scrum Guide 2020 divides sprint planning into three topics. Knowing who leads which part tells you what to prepare and when to let the team speak.

The three topics of sprint planning Based on the Scrum Guide 2020. The PO leads the first, the Developers own the last.

Why: The PO proposes the sprint's value; the whole team agrees the Sprint Goal
What: The Developers select backlog items in discussion with the PO
How: The Developers plan how to turn the work into a usable Increment

If the “what” discussion shows the goal no longer fits, go back and revise the Sprint Goal before the meeting ends.

For the “why” topic, the Scrum Guide says the PO proposes how the product could increase its value in the sprint, and then the whole Scrum Team defines the Sprint Goal. The Sprint Goal must be finalized before the meeting ends.

For the “what” topic, the Developers select items from the Product Backlog through discussion with the PO. Scrum.org notes that the team's forecast is more reliable when they understand their past performance, upcoming capacity and Definition of Done. For the “how” topic, the Scrum Guide says it is entirely up to the Developers.

On length, the Scrum Guide sets a maximum of eight hours for a one-month sprint. Shorter sprints usually mean a shorter meeting. A meeting that drags on can be a sign the backlog was not prepared.

What the PO does and does not do in sprint planning
Area	The PO should	The PO should not
Sprint goal	Propose a goal and explain why	Fix the goal without listening to the team
Selecting work	Give the order and answer questions on value and scope	Decide how many items the team must take
Estimates	Clarify requirements so the team can estimate better	Hand out days or points for each item
How the work is done	Be available when the team has questions	Assign tasks to individuals

What should you prepare a day or two before sprint planning?

Preparing a day or two ahead gives you time to check with your manager, operations or engineers when you find a gap. Leave it to the night before and there is no one left to ask.

Review the Product Goal and the last sprint. What got done, what is unfinished, and has any user or stakeholder feedback changed priorities?
Write a proposed Sprint Goal. One sentence saying what value this sprint brings and for whom. It is a proposal, not the final decision.
Order the top of the backlog. You do not need to order all forty items. Just the ones likely to enter this sprint, plus a few spares. If several people are pushing their priorities on you, see the article on prioritising the backlog.
Check the top items are clear enough. Each should have a user, a problem, a scope and acceptance criteria. If your team has a Definition of Ready, use it to check.
Note dependencies and risks. Which items need another team, data, a decision from your manager, or a finished design first?
Ask about capacity in advance. Who is on leave, who is on support duty, are there holidays or releases that take time? This is information for the team to work with; you only gather it.
Anticipate questions. Read each item as an engineer would: where will someone ask “what about this case”? Answer it beforehand, or note clearly that it is still unknown.

If the top items are not ready, the best place to fix that is the refinement session before planning, not planning itself. The Scrum Guide describes refinement as breaking down and further defining backlog items, and says the people who will do the work are responsible for sizing.

How does the PO run the “what” conversation?

Once there is a proposed Sprint Goal, the “what” part is a conversation between you and the Developers. You bring the order and the reasons. The team brings its understanding of difficulty, risk and its own capacity. Mountain Goat Software stresses that sprint planning should be collaborative rather than a handoff of assignments.

A simple sequence you can use:

Open with the goal. Read the proposed Sprint Goal and say why it matters now. Ask the team: does this goal make sense given where we are?
Work from the top down. Introduce each item in order, briefly covering the user, the problem and how we will know it is done. Let the team ask; do not read out the whole document.
Let the team stop. When the Developers feel they have enough, they say so. You do not need to push more. If there is room, you suggest the next item.
Check against the goal. Look at the selected list: does it really serve the Sprint Goal? If not, change the list or change the goal.
Capture the unknowns. Write down unanswered questions, who will answer them and by when.

When the team asks something you do not know, say so plainly and agree when you will answer. Guessing in the meeting can lead the team to build on a rule nobody confirmed.

What if capacity is less than you want?

Capacity is how much the team can actually do in this sprint, after leave, support work, meetings and release work. Mountain Goat Software notes that velocity from past sprints can inform the conversation, but capacity in the sprint being planned is what counts.

When the wanted work exceeds capacity, pushing the team to take more does not increase capacity. It only makes the plan less believable. There are four directions worth considering.

Four directions when work exceeds capacity The PO proposes a direction; the Developers judge whether the work fits.

Narrow the goal: Keep the single most important outcome and drop the nice-to-haves. A small goal that is met beats a large one left half done.
Split backlog items: Ask the team: is there a smaller version that still solves the main problem? Build the main flow first and leave rare cases for a later sprint.
Change the order: Move another item to the next sprint to protect the more important one. Tell the affected stakeholders right after the meeting.
Tell people early: If no direction keeps a deadline, tell the requester now, with an alternative.

What not to do is keep the list as it is and hope the team works late. The Scrum Guide has a mechanism for when work turns out different from expected: the Developers work with the PO to renegotiate scope within the sprint, without affecting the Sprint Goal. That only works when the goal is clear enough to show which parts can be cut.

Example: weak and better Sprint Goals

Back to the tea-ordering app. The table below shows illustrative examples. The numbers in the “Better version” column are assumed; a real team would use its own.

Sprint Goals before and after revision (illustrative)
Weak version	Problem	Better version
Finish 8 tickets this sprint.	Counts work, says nothing about value or for whom.	Regular customers can reorder a past order from their order history without picking each item again.
Build reorder, fix the payment bug, redo the cart.	Three goals glued together are not one goal.	Customers paying by e-wallet are no longer charged twice (currently about 1% of orders, an assumed figure).
Improve the user experience.	No way to tell when it is met.	New customers complete their first order without calling the hotline to ask about delivery fees.
Complete 100% of the selected backlog.	Turns the list into the goal and removes room to negotiate scope.	Before the promotion, regular customers can reorder a past order in the app. Filtering by tea type can wait for the next sprint.

What the better versions share: they say who benefits, what they gain, and give a visible sign of when it is met. The last one also says what can be cut if the work proves harder than expected. That is when a Sprint Goal earns its keep: it helps the team decide what to cut without asking the PO about every detail.

In the opening situation, if the team picks the reorder goal, the payment bug can still enter the sprint as a separate item if there is capacity. It does not need to be in the Sprint Goal sentence. The Scrum Guide calls the Sprint Goal the single objective for the sprint, not a list of everything the team will do.

Prep checklist and Sprint Goal template

Both templates below are ready to use. Copy them into your notes and adjust them to the names your team uses.

Sprint planning prep checklist

A day or two before the meeting:
[ ] Reviewed the Product Goal and the last sprint's results.
[ ] Have a proposed Sprint Goal in one sentence.
[ ] Ordered the items likely to enter the sprint, plus a few spares.
[ ] Each top item has a user, a problem, a scope and acceptance criteria.
[ ] Noted dependencies: other teams, data, design, pending decisions.
[ ] Gathered capacity information: leave, support duty, holidays, releases.
[ ] Read each item as an engineer would and answered likely questions.
[ ] Know which part of the goal can be cut if time runs short.

During the meeting:
[ ] Open with the goal and the reason.
[ ] Let the Developers choose how much to take and how to do it.
[ ] Check the selected items serve the goal.
[ ] Finalize the Sprint Goal before the meeting ends.
[ ] Record open questions, who answers them and by when.

Sprint Goal template

By the end of this sprint, [who] can [do what],
so that [outcome or problem solved].
We will know it is met when [visible sign].
If time runs short, the part that can wait is [part that can be cut].

The last line is easy to skip but worth keeping. It makes you and the team agree in advance on what is core and what is extra, so when the sprint hits trouble, the scope conversation is faster.

Common mistakes new POs make in sprint planning

Arriving without a goal. The meeting becomes ticket picking, and at the end of the sprint nobody can say what it was for.
Assigning tasks and dictating estimates. This takes away the Developers' decisions and can make estimates less accurate, because the people doing the work understand its difficulty best.
Writing requirements during the meeting. If an item needs more than a few minutes to explain, it may not be ready; consider sending it back to refinement.
Gluing several goals into one sentence. When everything is the goal, the team does not know what to cut when things get hard.
Staying quiet when the plan is overloaded. If you see the team taking on more than it can, ask directly: what could we leave for later and still meet the goal?
Promising stakeholders before the meeting. Promising a release date before the team has selected the work puts everyone in a difficult position.

Summary

Sprint planning answers three questions: why (the Sprint Goal), what, and how. The PO leads the first; the Developers own the last.
Prepare a day or two ahead: propose a Sprint Goal, order the top of the backlog, check clarity, note dependencies, gather capacity information.
In the meeting, the PO brings the order and the reasons. The Developers choose how much to take and decide how to do it.
When work exceeds capacity: narrow the goal, split items, change the order, or tell people early.
A good Sprint Goal says who benefits, what they gain, how you will know it is met, and what can wait.

I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.

Get new articles by email

Frequently asked questions

What should a Product Owner prepare before sprint planning?

A proposed Sprint Goal, an ordered top of the backlog that is clear enough to discuss, and answers to the questions the team may ask about value, scope and acceptance criteria. Prepare a day or two ahead so there is time to check with the people involved.

Who decides how much work goes into a sprint?

According to the Scrum Guide 2020, the Developers select the Product Backlog items for the sprint, through discussion with the Product Owner. The PO proposes the order and explains the value but does not dictate the amount or the estimates.

What is a Sprint Goal?

The Sprint Goal is the single objective for the sprint and says why the sprint is valuable. The PO proposes it, the whole Scrum Team agrees on it, and it must be finalized before sprint planning ends.

Sources to check

What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.