Skip to content

Sprint Planning Worksheet

At a glance

  • Purpose: Run sprint planning as a working session that ends with a committed goal and a plan the team believes, rather than a status update.
  • Use it when: At the start of every sprint or iteration. Allow roughly two hours for a two-week sprint.
  • Owner: The product owner brings the ordered backlog; the team produces the plan.
  • Related: Module 04 · Lab 15

How to use this template

  1. Start from capability, not aspiration: subtract leave, meetings, support, and onboarding from the calendar before deciding what fits. Teams over-commit when they plan against the calendar.
  2. Choose a sprint goal — one sentence of outcome. A list of unrelated items is not a goal, and without a goal the team cannot make sensible trade-offs mid-sprint.
  3. Select items from the top of the ordered backlog until the capacity is used. Stop early rather than filling to 100%; unresolved defects and interruptions always consume some capacity.
  4. Break the selected items into tasks, each small enough to be started without further discussion, and ask what could stop each one.
  5. Record the forecast and its basis. The basis is what makes the next sprint's plan better.

Field descriptions

Field What goes in it Watch out for
Sprint goal One outcome, in business terms A restatement of the item list
Capacity Available person-days after deductions Using calendar days
Deductions Leave, ceremonies, support, onboarding Forgetting the work that is not in the sprint
Selected items Items meeting the definition of ready Items chosen because they were convenient
Tasks Steps, with a rough size and an owner Tasks per person rather than per outcome
Blockers What could stop the work, and who can clear it Risks with no named owner
Forecast basis Why the team believes the amount fits "We did the same last time" alone
Commitments What will be shown at the review Unstated expectations

Blank template

# Sprint Planning — [Sprint n]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Sprint window** | [Start] – [End], [n] working days |
| **Last sprint's completed work** | [Points or items — state what carried over, if anything] |

## 1. Sprint goal

> [One sentence naming the outcome the sprint will produce.]

## 2. Capacity

| Person / role | Working days | Deductions | Available |
| --- | --- | --- | --- |
| [Role] | [n] | [leave 2, support 1, ceremonies 0.5] | [n] |
| **Total** | | | **[n]** |

Notes: [any ramp-up, part-time, or shared-resource effect on this amount]

## 3. Selected items

| Order | ID | Item | Estimate | Acceptance criteria agreed? |
| --- | --- | --- | --- | --- |

**Total selected:** [n] · **Capacity:** [n] · **Headroom kept:** [n]

## 4. Tasks

| Item | Task | Owner | Size (rough) |
| --- | --- | --- | --- |

## 5. Risks and blockers

| # | What could stop us | Likelihood | Action | Owner | By when |
| --- | --- | --- | --- | --- | --- |

## 6. Forecast and basis

[Why the team believes this amount will finish. Include what is different from last sprint, and
what the team will do first if the goal comes under threat.]

## 7. Definition of done reminder

[Link or restate the agreed definition of done for this team.]

## 8. Agreements

| Item | Decision |
| --- | --- |
| [Anything decided about how the sprint will run] | [Decision] |

Worked example

From Lab 15, invented for teaching. A three-person team planning a two-week sprint:

Person / role Working days Deductions Available
Backend developer 10 leave 1, support 1, ceremonies 1 7
Frontend developer 10 ceremonies 1 9
Tester (shares 0.5 with another project) 5 ceremonies 0.5 4.5

Total capacity 20.5 person-days. The team selects items summing to 18, keeping 2.5 days of headroom. Two details in this example carry most of the lesson:

  • The tester is available for 4.5 days, not 10. Planning as if testing were free is the single most common cause of a sprint ending with unverified work — which then fails the definition of done.
  • The forecast is attributed: "17 points completed last sprint with the same team minus one day of leave; 18 chosen because the eligibility item is split and the test cases already exist." That sentence is what makes the plan challengeable, and it is what the team should be able to say when asked why this number and not another.

Common mistakes

  • Planning against the calendar instead of available capacity. Leave, support, and ceremonies are real work absences.
  • Filling capacity to 100%. Interruptions are certain; headroom is the cheapest insurance available.
  • No sprint goal. Without one, every trade-off mid-sprint becomes a negotiation about preferences.
  • Taking items that fail the definition of ready. Unknown work gets estimated optimistically and discovered late.
  • A plan that is a task list per person. It optimises individual loading, not the outcome, and it makes the team unable to help each other.
  • A forecast with no stated basis. Repeatable estimation depends on knowing why the last forecast was right or wrong.
  • Treating the plan as a commitment to the sponsor. It is a forecast the team owns; the goal is the commitment.