Sprint planning with estimates: from backlog to sprint goal

Sprint planning is the Scrum event that starts every sprint. The whole Scrum team agrees why the sprint is valuable (the sprint goal), what can be done (the backlog items the developers select) and how the chosen work will get done (the developers’ plan). Estimates help with the middle question: a velocity range, adjusted for this sprint’s capacity, tells the team roughly how much it can take on.

The Scrum Guide timeboxes sprint planning to a maximum of eight hours for a one-month sprint, and the event is usually shorter for shorter sprints. With a well-refined backlog, a two-week sprint can often be planned in about 90 minutes. This guide walks through the three topics, shows how to use velocity and capacity, and gives you a sample agenda and the traps to avoid.

What is sprint planning?

In the Scrum Guide’s words, “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.” The plan is created by the whole Scrum team working together. The product owner makes sure attendees are prepared to discuss the most important backlog items and how they map to the product goal, and the team can invite other people to give advice.

The output is the sprint backlog, which the guide defines as three things together: the sprint goal (why), the product backlog items selected for the sprint (what) and an actionable plan for delivering the Increment (how).

The 2020 edition organises the event around three topics, adding “why” to the older “what” and “how”. The order matters. A team that fills the sprint with tickets first and then writes a goal to describe them has planned the sprint backwards.

Topic one: why is this sprint valuable?

The product owner proposes how the product could increase its value and utility in this sprint. The whole Scrum team then shapes that into a sprint goal, which the guide says “must be finalized prior to the end of Sprint Planning”.

A good sprint goal is a single objective with a visible outcome. It gives the team focus and leaves room to adjust the detailed scope during the sprint. Compare:

The Scrum Guide calls the sprint goal a commitment by the developers, while noting that it “provides flexibility in terms of the exact work needed to achieve it”. A goal written as a list of tickets throws that flexibility away: if one ticket slips, the goal fails, even when the outcome could still have been reached another way.

Topic two: what can be done this sprint?

“Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.” Note who selects: the developers, not the product owner or a manager. The guide then names three things that make the selection more confident: the developers’ past performance, their upcoming capacity and their Definition of Done.

Past performance is your velocity range, and upcoming capacity adjusts it for this particular sprint. Here is how that works for a team whose recent velocity is 26 to 32 points:

1. Check capacity. The five-person team has a bank holiday on the Monday, and one person is on leave for three days. That is 42 of a normal 50 person-days, or 84%.
2. Scale the range. 84% of 26 to 32 gives roughly 22 to 27 points.
3. Select towards the lower half. Pull items that serve the goal, in backlog order, until you reach about 22 to 24 points.

With the goal “Returning customers can pay with a saved card”, the selection might look like this:

Twenty-three points sits in the lower half of the range, and most of it serves the goal. The next ready item, “Show saved cards in the mobile app”, stays at the top of the product backlog in case the sprint goes well. Our guide to velocity and forecasting explains how to build the range and adjust it for capacity.

The guide also lets the team refine items during planning. A quick estimate for a newly discovered item is fine, but if most items need one, refinement isn’t keeping up; see our guide to backlog refinement.

Topic three: how will the chosen work get done?

For each selected item, the developers plan the work needed to meet the Definition of Done. The guide notes this “is often done by decomposing Product Backlog items into smaller work items of one day or less”, and that “How this is done is at the sole discretion of the Developers.”

In practice, topic three is where the plan gets real:

• Break the first few items into tasks of a day or less, starting with the riskiest.
• Agree who will pair or swarm on what, rather than assigning every task to a name on day one.
• Flag dependencies, such as access to the payment provider’s test environment, and decide who will chase them.
• Agree how each item will be tested against the Definition of Done.

You don’t need tasks for the whole sprint before you start. The sprint backlog is updated throughout the sprint as more is learned, so plan the first few days in detail and the rest in outline. If planning the how reveals far more work than the estimates suggested, go back to topic two: drop an item and keep the goal.

Story points and tasks do different jobs. Points helped you decide how much to take on, and tasks help you do it. There is no need to convert one into the other, and many teams don’t estimate tasks at all.

How long should sprint planning take?

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.” Many teams scale the maximum down in proportion, giving up to four hours for a two-week sprint and two hours for a one-week sprint.

That is a ceiling, not a target. When the backlog is refined, the goal is drafted and capacity is known before the meeting, a two-week sprint can often be planned in about 90 minutes, as in the sample agenda below. If your planning regularly hits the timebox, the meeting usually isn’t the problem: the work arriving in it isn’t ready, and a short Definition of Ready can help.

What to prepare before sprint planning

• The product owner brings an ordered backlog with at least a sprint’s worth of ready items, a draft objective for the sprint, and anything learned in the sprint review that changes priorities.
• The developers bring their availability (leave, training, on-call duty), the state of any unfinished work, and improvement actions from the retrospective.
• The Scrum master, or whoever facilitates, brings the velocity range from recent sprints, books the time and invites any advisers the team wants.

Tip Ask everyone to put their days off for the coming sprint in one shared place a day before planning. Working out capacity at the start of the meeting eats ten minutes and is easy to get wrong.

A sample sprint planning agenda

This agenda fits a two-week sprint into a 90-minute timebox. Adjust the timings to your team.

1. Open and set context (5 minutes). Confirm the timebox. The product owner recaps the product goal and what the last sprint review taught you, and the team confirms capacity and the velocity range.
2. Why: draft the sprint goal (15 minutes). The product owner proposes an objective. The team asks questions and shapes a draft goal.
3. What: select the work (25 minutes). The developers pull ready items that serve the goal, in order, and check the total against the capacity-adjusted range. Estimate anything new with a quick round of planning poker.
4. How: plan the first days (30 minutes). Break the first items into tasks of a day or less, starting with the riskiest. Agree pairing and flag dependencies.
5. Confirm (10 minutes). Read the sprint goal aloud and finalise its wording. Ask for a quick confidence vote, such as a fist of five, and adjust the scope if confidence is low.

That leaves five minutes of slack, which you will use.

On planningpoker.org When a new item turns up in planning, anyone can open a free guest session and share the link, and people join with just a name. With a free Laya account and a Jira connection, you can pick the issue from your Jira board, and Save & Next can write the agreed estimate back to Jira, by default to the board’s own estimation field.

Common sprint planning traps

• Turning planning into refinement. If the team is reading most items for the first time, planning overruns and the estimates are rushed. Refine continuously, so planning starts with ready work.
• Planning to your best sprint. Filling the sprint to the top of the range, or beyond it, leaves no room for the incident that always comes. Plan towards the lower half.
• A goal that is a list of tickets. It gives no focus and no room to adapt. Write an outcome instead.
• Someone else deciding how much. When a manager or the product owner sets the number of points, the plan stops being the developers’ forecast and becomes a quota.
• Treating the forecast as a promise. The Scrum Guide expects that scope “may be clarified and renegotiated with the Product Owner as more is learned”, as long as nothing endangers the sprint goal.
• Carrying work over on autopilot. Unfinished items go back to the product backlog, so decide on each one explicitly. Priorities may have changed since last sprint.
• Taking in stories that are too big. A story that fills half the sprint puts the goal at the mercy of one item. Split it during refinement, before it reaches planning.