Skip to content

Lab 15 — Running Sprint Planning

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Write a sprint goal that describes an outcome rather than a list of items.
  2. Break backlog items into tasks small enough to track daily.
  3. Test a sprint plan against real capacity, not against optimism.
  4. Write a definition of done whose items are checkable, and explain what it prevents.

Scenario

This lab continues the E-Commerce Platform from Lab 14. The four-sprint release has been ordered, and sprint 1 has been selected. The sprint runs for two weeks, from Monday 6 April to Friday 17 April 2026, with no public holidays.

Sprint 1 contents, agreed with the product owner:

ID Item Points
B1 Cart persistence across sessions 5
B3 Payment retry handling 3
B12 Order tracking 8
B11 Address book 3
Total 19

Delivery facts:

Fact Value
Team 3 developers, 1 tester, 1 designer
Sprint length 10 working days
Non-project time 20% of capacity
Measured velocity 18 points per sprint (from the previous three sprints)
Historical throughput 19 points completed in roughly 40 person-days of work
Definition of done Does not yet exist — you are writing it in Task 5
Environments One shared test environment; deployments are manual
Code review Required for all changes; two developers can review

Two things arrive during sprint planning:

  • The designer will be unavailable for four days because of a previously agreed commitment to another product.
  • The finance manager asks for B10 (gift cards) to be pulled into this sprint instead of B11, because a supplier promotion starts in six weeks. B10 is 13 points and depends on B2 (guest checkout), which is not yet done.

Your role

You are the Scrum Master facilitating planning. You do not decide what goes into the sprint; the team does, with the product owner. Your responsibilities are to keep the conversation at the right level of detail, to make capacity visible, and to prevent the sprint from being overloaded.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Use 19 points × 40 person-days ÷ 18 points ≈ 2.1 person-days per point as the rough conversion between points and effort for this team. State that it is an approximation when you use it.
  • Non-project time applies to the team's total capacity, not to each task.
  • Assume the shared test environment is available throughout, but only one deployment can run at a time.
  • Assume the finance manager's request is commercially real but not a sprint emergency.

Tasks

Task 1 — Write the sprint goal

Write one sentence describing what will be true at the end of the sprint for a customer or for the business. It must not be a list of item names.

Then rewrite it twice: once as a goal that would be met even if one item slips, and once as a goal that would only be met if everything lands. State which version you would actually use and why.

Task 2 — Calculate the real capacity

Build the capacity table:

Resource Days available At 80% Notes
Developer 1 10
Developer 2 10
Developer 3 10
Tester 10
Designer 10 Four days committed elsewhere
Total person-days

Then:

  1. State the team's available person-days for the sprint.
  2. Convert the sprint's 19 points into estimated person-days using the given conversion.
  3. Compare (1) and (2). State whether the sprint fits, and by how much it does or does not.
  4. State what the comparison tells you about the number of points the team should commit to.

Task 3 — Break down the items into tasks

For each of the four items, produce the tasks required to meet the definition of done you write in Task 5. Each task must be:

  • assignable to one person
  • no larger than one day
  • named as an action with an identifiable output

Present as a table:

Item Task Owner role Estimate (person-days) Depends on

Then total the task estimates and compare with your capacity from Task 2. If the total exceeds capacity, say what you would remove or split, and why.

Task 4 — Handle the two interruptions

The designer's four-day absence.

  1. State exactly which tasks are affected.
  2. Give two options for handling it, with the cost of each.
  3. Choose one, and state what you accepted as the consequence.

The finance manager's request.

  1. State the dependency problem in one sentence.
  2. State the capacity problem in exact numbers.
  3. Write the response you would give — as Scrum Master, not as the business owner — in four or five sentences. It must be accurate about both problems without being a refusal, and it must give the finance manager something they can act on.

Task 5 — Write the definition of done

Write a definition of done for this team with at least eight checkable conditions. Cover, at minimum: code review, automated tests, manual testing, accessibility, the shared test environment, documentation, and the product owner's acceptance.

Then answer:

  1. What does each condition prevent? Give one example.
  2. Which condition would you expect to be the first to be waived under pressure, and what would you do about that?
  3. How does the definition of done change the number of tasks in Task 3?

Task 6 — Plan the deployment

Only one deployment can run at a time on the shared environment, and deployments are manual.

  1. Sequence the sprint's deployments so that no two collide.
  2. State when the tester needs a stable environment, and what that requires from the developers.
  3. Identify the point in the sprint at which testing is most at risk, and the mitigation.

Task 7 — State what would make this sprint fail

Write five bullet points, each naming a specific and plausible failure mode for this sprint — not generic project risks. For each, state the early sign you would watch for.

Deliverable

  1. The sprint goal, in three versions, with your choice and reasoning.
  2. The completed capacity table, the point-to-effort conversion, and your verdict on fit.
  3. The task breakdown table for all four items, totalled and compared with capacity.
  4. Your handling of the designer's absence and the finance manager's request.
  5. A definition of done with at least eight checkable conditions and the three answers.
  6. The deployment sequence and the testing-risk mitigation.
  7. Five sprint-specific failure modes with early signs.

Hints and guidance

  • A sprint goal names an outcome. "Deliver cart persistence, payment retry, order tracking, and the address book" is a list; it tells nobody what to do when a trade-off appears mid-sprint.
  • Not all of a person's 10 days are available. Apply the 20% before you plan, not after you fail.
  • Tasks, not items, reveal over-commitment. Four items look small; thirty tasks do not.
  • The designer's absence is not a reason to reduce the sprint by four days. Only the tasks that actually need design are affected.
  • A dependency cannot be solved by capacity. B10 cannot start before B2 regardless of how many people are free.

Self-check criteria

Check How to verify it
Goal is one sentence and outcome-based No item names appear in it
Capacity arithmetic correct 80% applied to each person, with the designer's four days removed
Conversion stated and applied 19 points × 2.1 ≈ 40 person-days, and you say it is an approximation
Verdict is explicit The sprint fits or does not, with the number
Tasks are one day or smaller Scan the estimate column; none exceeds 1.0
Task totals reconcile with capacity Sum of task estimates compared with available person-days
Definition of done is checkable Each condition can be judged met or not met by a third party
Deployment sequence has no collisions One deployment at a time, in order
Failure modes are specific Each names something that could happen in this sprint

Reflection

  1. Did the sprint fit? What did the answer tell you that the point total alone did not?
  2. Which is the more useful artefact — the sprint goal or the task list? Argue for one, then state what the other does that the first cannot.
  3. The finance manager is a stakeholder with a real commercial deadline. What could you offer them today that is honest and useful, without breaking the sprint?
  4. If the definition of done is waived "just this once" for B3, what is the cost, and who pays it?
Check your numbers
  • Capacity: developers 3 × 10 = 30; tester 10; designer 10 − 4 = 6 → 46 person-days gross. At 80%: (30 × 0.8) + (10 × 0.8) + (6 × 0.8) = 24 + 8 + 4.8 = 36.8 person-days.
  • Sprint demand: 19 points × 2.1 ≈ 40 person-days using the historical conversion. If you use the historical figure directly, 19 points took roughly 40 person-days.
  • Verdict: the sprint does not fit as scoped. The shortfall is roughly 3 person-days — about 1.5 points. The honest commitment is nearer 17 points.
  • Designer absence: four design days are lost, which is why the designer contributes 4.8 rather than 8 person-days.

Full working, including a model task breakdown and deployment sequence, is in the Intermediate labs answer key.

Extension challenge

Run the same sprint with no non-project time allowance and report what changes: the capacity figure, the commitment, and the likely outcome by day eight. Then write the single paragraph you would use to explain to a manager why "100% utilisation" produces worse delivery performance than 80% — using your own arithmetic rather than a general statement.