Skip to content

Lab 14 — Creating a Scrum Product Backlog

At a glance

Learning objectives

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

  1. Turn a set of feature requests into a sized, ordered product backlog.
  2. Order a backlog by value and dependency rather than by who asked loudest.
  3. Forecast a release from measured velocity, and state the forecast's assumptions.
  4. Explain why story points are not hours, and what breaks when they are treated as hours.

Scenario

This lab uses the E-Commerce Platform from Lab 06, now in delivery. The retailer has adopted Scrum: two-week sprints, a product owner (the business owner), and a delivery team of three developers, one tester, and one designer.

The initial backlog has been sized by the team using story points. Requests come from several sources, listed here with the product owner's value rating (1 = low, 5 = high):

ID Item Points Value Depends on Requested by
B1 Cart persistence across sessions 5 4 — Product owner
B2 Guest checkout 8 5 B1 Business owner
B3 Payment retry handling 3 5 — Finance manager
B4 Wishlist 5 2 — Marketing
B5 Product reviews 8 4 — Marketing
B6 Review moderation 5 3 B5 Operations
B7 Search filters 8 3 — Customers (support tickets)
B8 Recommendation strip 13 2 B5 Marketing
B9 Loyalty points 13 3 B2 Business owner
B10 Gift cards 13 2 B2 Finance manager
B11 Address book 3 2 — Customers (support tickets)
B12 Order tracking 8 5 — Customers (support tickets)
B13 Returns flow 8 3 B12 Operations

Delivery facts:

Fact Value
Sprint length 2 weeks
Sprints before the winter season 4
Measured velocity (last 3 sprints) 18 points per sprint
Team composition 3 developers, 1 tester, 1 designer
Planned absence One developer on leave throughout sprint 2
Non-project time 20% of capacity (meetings, support, leave)

Your role

You are the Scrum Master. You do not decide priority — the product owner does. Your job is to make the consequences of the priority order visible, and to ensure the team can discuss the backlog with sized, comparable items.

Project information and assumptions

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

  • Story points are relative and team-specific. They are as sized; do not re-size them unless you state a reason and apply it consistently.
  • Velocity is a measurement from the last three sprints, not a target. Treat it as the best current evidence.
  • Dependencies are hard: an item cannot start before the items it depends on are done.
  • Total backlog size: 100 story points. Verify this yourself in Task 1.
  • Assume no item can be partially delivered in a way that produces value.

Tasks

Task 1 — Verify the size

Sum the points and confirm the total. Then, in two or three sentences, explain what "1 story point" means for this team, and what it does not mean.

Task 2 — Calculate the release forecast

  1. Calculate the total capacity in points across four sprints, accounting for the absence and for non-project time. Show the arithmetic.
  2. State which of the four sprints your capacity calculation affects, and by how much.
  3. Explain why the answer is a forecast and not a commitment, and name two things that would invalidate it.

Task 3 — Order the backlog

Produce a single ordered list of all thirteen items, most important first. Explain your ordering rule in two or three sentences, then justify the position of the five items you placed first.

Your ordering must satisfy three constraints:

  1. No item appears before an item it depends on.
  2. Value is respected — but value alone does not determine order.
  3. At least one high-value item is deliberately deferred, and you explain why.

Task 4 — Select the release contents

From your ordered list, take the items that fit within your four-sprint capacity.

  1. State the items selected and their total points.
  2. State the items deferred, their total points, and the reason for each deferral — noting that for items with dependencies, deferring a parent defers its children.
  3. Calculate the proportion of total value delivered, using the value ratings. Show the arithmetic.
  4. Answer: did maximising value delivered produce the smallest deferred set? If not, which two objectives conflict, and which did you choose?

Task 5 — Deal with the dependency cascade

B5 (Product reviews, 8 points, value 4) gates two other items: B6 (5 points, value 3) and B8 (13 points, value 2).

  1. Calculate the total points and value of the full cascade.
  2. Decide whether to include the cascade in this release, and justify your decision using the numbers.
  3. Explain what happens to B6 and B8 if B5 is deferred — and why "we will do reviews later, and moderation then" is or is not a coherent plan.

Task 6 — Write the definition of ready

A backlog item is only "ready" for sprint planning when the team can estimate and commit to it. Write a definition of ready for this team with at least six checkable conditions. Then state what happens when an item is pulled into planning without meeting them.

Task 7 — The re-estimation request

The finance manager, whose items are B3 and B10, asks for the points to be converted into hours so that Finance can see a cost.

  1. Explain what would happen to the team's estimation behaviour if you did that permanently.
  2. Give the finance manager what they actually need, without breaking the backlog — describe the mechanism in three or four sentences.

Deliverable

  1. The verified total and your explanation of what a story point means here.
  2. The release forecast, with arithmetic and two invalidating factors.
  3. The ordered backlog of all thirteen items with your ordering rule.
  4. The release contents: selected, deferred, value proportion, and the conflict you resolved.
  5. The dependency cascade analysis.
  6. A definition of ready with at least six checkable conditions.
  7. Your answer to the finance manager's request.

Hints and guidance

  • Order by value per unit of risk and cost of delay, not by points. A large, valuable item may legitimately come after a small, blocking one.
  • Dependencies are ordering constraints, not priorities. A low-value parent can still have to come first if two high-value children need it — and that is a decision to make explicitly, not to inherit.
  • Velocity forecasts only if it is not treated as a target. Say so when you present the forecast.
  • A definition of ready protects the sprint. Without one, planning becomes requirements gathering with the whole team watching.

Self-check criteria

Check How to verify it
Total points verified 100, matching the sum of the column
Capacity arithmetic shown Absence and non-project time both applied, and the affected sprint named
Ordering satisfies dependencies No item precedes a dependency anywhere in the list
Ordering rule is stated and applied consistently You can explain where each of the first five sits
One high-value item is deferred with a reason Named, with the trade-off stated
Value proportion calculated Sum of selected values ÷ sum of all values
Cascade arithmetic correct B5 + B6 + B8 = 26 points, total value 9
Definition of ready is checkable Each condition could be judged by a third party as met or not met

Reflection

  1. Which item was hardest to place, and what did the difficulty come from — value, dependency, or size?
  2. Your forecast assumes velocity stays at 18. What could make it fall, and how early would you know?
  3. If the business owner insisted on all four of their items, what would you remove, and how would you present the removal?
  4. Story points are not hours. What is the legitimate way to answer a question about cost?
Check your numbers
  • Total backlog: 5 + 8 + 3 + 5 + 8 + 5 + 8 + 13 + 13 + 13 + 3 + 8 + 8 = 100 points.
  • Nominal capacity: 18 × 4 = 72 points.
  • Absence: one developer throughout sprint 2. With five people, that is 20% of the team for one of four sprints → 18 × 0.2 = 3.6, so roughly 4 points lost in sprint 2. A defensible answer between 3 and 5 points is acceptable if the reasoning is shown.
  • Non-project time: already reflected in the measured velocity of 18, because velocity is measured, not calculated from capacity. If you instead build capacity from scratch, apply the 20% and state that you did.
  • Capacity available: about 68 points, so roughly 68% of the 100-point backlog fits.
  • Dependency cascade: B5 + B6 + B8 = 8 + 5 + 13 = 26 points, with combined value 4 + 3 + 2 = 9.

Full working, including a model ordering and selection, is in the Intermediate labs answer key.

Extension challenge

The product owner proposes replacing story points with throughput — simply counting the number of backlog items completed per sprint — because it is easier to explain to the finance manager. Assess the proposal honestly: state what would be gained, what would be lost, and what could go wrong if item sizes vary widely. Then design a two-measure reporting scheme that satisfies both the team and Finance, and justify each measure against the decision it supports.