Sprint Backlog Example and Template: Plan a Sprint Step by Step

This guide builds a real sprint backlog from scratch, from capacity through to the end of the sprint, using one worked example you can copy. You’ll get a capacity calculation, a sprint backlog template with tasks, and a way to change the plan mid-sprint without losing the goal. For what a sprint backlog is, why it needs a Sprint Goal and how to lay out the board, read The sprint backlog explained first.

One team runs through every step. Five developers build the mobile ticketing app for a regional bus company. Their product owner wants riders to stop queuing at the driver’s window, and the next two-week sprint starts on Monday.

Who this is for

• New Scrum teams running Sprint Planning for the first few times.
• Scrum Masters whose sprint backlogs keep turning into individual to-do lists.
• Product owners who want to know what “ready for planning” needs to look like.

Before you start

• A refined, ordered product backlog. The top items have acceptance criteria and estimates. If they don’t, refine first; Sprint Planning isn’t the place to write stories.
• Your last three sprints’ results. What the team actually finished, in the unit you estimate in.
• Who’s available. Leave, public holidays, support rotas and anything else that takes people away.

Step 1: Work out capacity

Start from what the team has actually finished, not what it hopes to finish. Average the last three sprints, then adjust for availability:

Forecast = average completed × (person-days this sprint ÷ usual person-days)

Usual person-days is what the team normally has after Scrum events, support duty and other regular commitments. It doesn’t need to be precise; it needs to be honest.

In the scenario: the team finished 29, 26 and 31 points in its last three sprints, an average of about 29. It usually has 45 person-days in a sprint. This sprint one developer is on leave for three days, leaving 42. The forecast is 29 × 42 ÷ 45, about 27 points.

Step 2: Agree the Sprint Goal

The product owner proposes how the sprint could add the most value; the whole Scrum Team shapes that into one Sprint Goal. Write it as an outcome someone outside the team would recognise, in one sentence.

The Scrum Guide only requires the goal to be final by the end of Sprint Planning. I’d still agree a draft before choosing items, so the goal decides which items belong in the sprint, not the other way round.

In the scenario: the product owner wants riders buying tickets in the app. The developers point out that signal is poor on rural routes. The goal becomes: “Riders can buy a day ticket in the app and show it to the driver, even without signal.”

Step 3: Select the items that serve the goal

The developers choose items from the top of the product backlog that together meet the goal, in discussion with the product owner, up to the forecast. Leave some of the forecast unused, or fill it with stretch items the goal doesn’t depend on, so there’s room to absorb surprises.

For each item, ask: does the goal fail without it? If not, it’s either a stretch item or it waits.

In the scenario: three items are needed for the goal: buy a day ticket with a saved card (8), show the ticket to the driver (5) and make the ticket work offline (5). A known Android login bug (2) blocks some riders from buying at all, so it’s in too. That’s 20 points for the goal. Two stretch items the goal doesn’t depend on fill most of the rest: email a receipt (3) and purchase analytics (3). The total is 26 of the forecast 27.

Step 4: Plan how, in tasks of a day or less

For each selected item, the developers work out how they’ll build it. The 2020 Scrum Guide notes that this is often done by breaking items into work of one day or less. Small tasks show progress daily and make it obvious when something is stuck.

Don’t plan every task for the whole sprint on day one. Plan the first few days in detail and the rest roughly; the plan will change as you learn.

In the scenario: “Buy a day ticket with a saved card” breaks into six tasks, from “add day-ticket product to the fare service” to “end-to-end test on a real card”. “Make the ticket work offline” gets only two tasks for now, because the team needs a short investigation before it can plan the rest.

Step 5: Decide the order and who starts where

Agree which items to start first and how many to work on at once. Start with the riskiest item for the goal, and finish items before starting new ones. Don’t assign every task to a person at planning; people pick up the next task when they’re free.

In the scenario: the offline ticket is the riskiest item, so two developers start there with the investigation. Two start on buying a ticket. One fixes the Android login bug, then joins the ticket work. The team agrees to have no more than three items in progress at once.

Step 6: Keep it current every day

The developers update the sprint backlog as work happens: tasks added, tasks done, items blocked. At the Daily Scrum, start with the Sprint Goal: are we on track for it? Then look at what’s blocked and where help is needed.

New tasks appearing mid-sprint is normal; it’s how the plan gets better. New items appearing without a conversation is not.

In the scenario: the offline investigation finishes on day 2. The team adds five tasks to the offline item, covering storing the ticket securely on the phone and showing a validity check without a connection. The item is now clearly bigger than 5 points.

Step 7: Change the scope, keep the goal

When the work turns out bigger than planned, the developers and the product owner agree what comes out, judged against the Sprint Goal. Drop stretch items first, then anything else the goal doesn’t need. The goal itself doesn’t change during the sprint. If it becomes obsolete, the product owner can cancel the sprint.

In the scenario: at the mid-sprint check on day 5, the offline work is about 3 points bigger than estimated. With the 1 spare point and the 3 from purchase analytics, there’s room. The developers and the product owner agree to drop purchase analytics, which goes back to the product backlog, and to keep the receipt email. The goal stays intact. (The burndown chart guide has a mid-sprint check you can use for this conversation.)

Step 8: Close the sprint honestly

At the end of the sprint, anything not done goes back to the product backlog, where the product owner orders it again. Don’t carry it into the next sprint automatically, and don’t split it to count the finished part.

Record what was completed. It feeds next sprint’s capacity calculation.

In the scenario: the four goal items and the receipt email are done, so the goal is met: riders can buy and show a day ticket offline. Purchase analytics, dropped on day 5, is in the product backlog for the product owner to order with everything else. The team finished 23 points, below its average, because the offline item grew. That’s useful information for next sprint’s forecast, not a failure.

Copy-paste templates

Capacity calculation

Sprint: ____
Dates: _______ to _______

Last three sprints:
____, ____, ____
Average: ____
Usual person-days: ____

This sprint
Developers x days: ____
- leave / holidays: ____
- support / other:  ____
= person-days:      ____

Forecast
= average x (this / usual)

Example
29 x (42 / 45) = 27 points

Sprint backlog

Sprint Goal:
Riders can buy a day ticket in
the app and show it to the
driver, even without signal.

Forecast: 27 points
Selected: 26 points
(20 for the goal + 6 stretch)

| # | Item                    | Pts | Goal?   |
|---|-------------------------|-----|---------|
| 1 | Ticket works offline    | 5   | Yes     |
| 2 | Buy ticket, saved card  | 8   | Yes     |
| 3 | Show ticket to driver   | 5   | Yes     |
| 4 | Fix Android login       | 2   | Yes     |
| 5 | Email a receipt         | 3   | Stretch |
| 6 | Purchase analytics      | 3   | Stretch |

Tasks for item 2
(each a day or less)
[ ] Add day-ticket product to
    the fare service
[ ] Payment call using the
    saved card
[ ] Purchase screen and
    confirmation
[ ] Handle declined cards
[ ] Store the ticket against
    the rider's account
[ ] End-to-end test on a real
    card

Mid-sprint scope change

Day: ____
Goal still achievable as
planned? yes / no
What changed:
_____________________________
Extra work: about ____ points

Take out, in this order:
1. Stretch items
   ________________________
2. Other items the goal
   doesn't need
   ________________________
3. Goal obsolete? Product
   owner decides whether to
   cancel the sprint

Agreed by (developers and
product owner):
_____________________________
Returned to product backlog:
_____________________________

Common mistakes

Choosing items before the goal. The backlog is filled from the top and a goal is written afterwards to describe it. Fix: agree a draft goal first, then select the items that serve it.

Planning to 100% of the forecast. Every point is committed, so any surprise means the goal fails. Fix: leave room, or make the last item a stretch item the goal doesn’t need.

Assigning every task at planning. Each developer leaves with a personal to-do list, and nobody swarms on the risky item. Fix: agree the order and who starts where; people pick up tasks as they free up.

Planning the whole sprint in detail. Two hours of tasks for day 9 that turn out wrong by day 3. Fix: plan the first few days in detail and the rest roughly, then add tasks as you learn.

Changing scope without the product owner. The developers quietly drop an item, or the product owner quietly adds one. Fix: scope changes are agreed between the developers and the product owner, against the goal.

Rolling unfinished work forward. Unfinished items move into the next sprint by default. Fix: return them to the product backlog and let the product owner order them again.

You’re done when

• The forecast comes from the last three sprints, adjusted for who’s available
• One Sprint Goal is written as an outcome, drafted before items were chosen
• Every selected item is either needed for the goal or marked as a stretch item
• The first few days are planned as tasks of a day or less
• The team has agreed what to start first and how many items to work on at once
• The sprint backlog is updated as work happens, not only at the Daily Scrum
• Scope changes are agreed by the developers and product owner, keeping the goal
• Unfinished items go back to the product backlog at the end of the sprint