Plan a sprint around a single Sprint Goal, choose work that fits the team's capacity and make a first plan.
Why it matters
Sprint Planning sets up everything that follows. A team that leaves planning with a clear goal and a realistic amount of work can make sensible trade-offs all sprint. A team that leaves with a long list of unrelated tickets and no goal will be busy, but nobody can say what the sprint was for, and the review becomes a list of half-finished items.
The three questions
The Scrum Guide frames Sprint Planning around three topics:
- Why is this sprint valuable? The Product Owner proposes how the product could increase its value, and the whole Scrum Team agrees a Sprint Goal.
- What can be done this sprint? The Developers select items from the Product Backlog that support the goal, based on their capacity and past performance.
- How will the chosen work get done? The Developers plan the work, often by breaking items into tasks of a day or less.
The Sprint Goal, the selected items and the plan together form the Sprint Backlog.
Writing a good Sprint Goal
A Sprint Goal is one objective that gives the sprint focus and coherence. It describes an outcome, not a list of tickets.
| Weak goal | Why it is weak | Better goal |
|---|---|---|
| "Finish tickets 41, 42, 45, 48 and 50" | A list, not an objective | "A member can book and cancel a court on their phone" |
| "Work on payments" | No end point | "Members can pay for a court booking by card in the app, in the test environment" |
| "Do as much as possible" | No focus at all | "Find out whether members will use reminders, by shipping one reminder to 50 testers" |
A good goal lets the team make decisions mid-sprint. If an item turns out larger than expected, the Developers and Product Owner can drop or simplify items while still meeting the goal. The Scrum Guide says the Sprint Backlog can be renegotiated during the sprint, but the Sprint Goal does not change.
Working out capacity
Before choosing items, the team works out how much time it really has. A worked example for Northside's two-week (10 working day) sprint:
Developers: 5 people x 10 days = 50 person-days
Minus planned leave: Priya 2 days, Sam 1 day = -3
Minus Scrum events and refinement (about 10%) = -5
Minus support rota (one person, 1 day per week) = -2
Available capacity = 40 person-days
Last 3 sprints with similar capacity: 21, 24, 23 story points completed
Average velocity = (21 + 24 + 23) / 3 = about 23 points
This sprint has about the same capacity, so plan for about 22-23 points.
Velocity (the points completed per sprint) is a forecasting aid for the team, not a target. Plan near your recent average, not your best-ever sprint.
Choosing the items
With the goal "A member can book and cancel a court on their phone" and about 23 points:
Browse free courts for a day 3 supports goal
Book a free court 5 supports goal
Cancel a booking (24h refund rule) 5 supports goal
Booking confirmation screen 3 supports goal
Limit of 3 future bookings per member 2 supports goal
Fix: login fails on older Android phones 3 needed: members cannot book if they cannot log in
---
21 points (2 points of slack for surprises)
The team leaves "Book a class" (13 points) in the Product Backlog. It is valuable, but it does not serve this sprint's goal and would overload the sprint.
Making the plan
For each item, the Developers sketch the work: design the screen, build the API call, write tests, accessibility check, update help text. Tasks of a day or less make progress visible at the Daily Scrum. They do not need to plan every task on day one; enough for the first few days is fine, and the plan grows as they learn.
The timebox is up to eight hours for a one-month sprint; for two weeks, about half that is common. A focused team with a well-refined backlog often needs much less.
Common mistakes
- No Sprint Goal, or a goal that is just the list of items.
- Overcommitting by planning to the best-ever velocity or ignoring leave.
- The Product Owner choosing the amount of work. The Developers decide how much they can take on.
- Planning poorly refined items, so the first days of the sprint go on working out what the items mean.
- Treating velocity as a performance target, which leads to inflated estimates.
Quick recap
- Sprint Planning answers why (Sprint Goal), what (items) and how (the plan).
- A good Sprint Goal is one outcome that guides trade-offs during the sprint.
- Work out real capacity, then plan near recent average velocity, leaving some slack.
- Choose items that serve the goal; leave the rest in the backlog.
Try it
Open the Do tab and plan a sprint with a goal and a capacity calculation.