The Sprint That Cannot Finish
You are the Scrum Master for a team of seven delivering an insurance claims intake product. Over the last four sprints, the team has committed to an average of 42 story points but completed an average of 29. The Product Owner, under pressure from a sales commitment, has begun adding items mid-sprint "because they're small." Two developers have started working on separate branches without integrating, and the last retrospective produced a list of six action items, none of which have an owner. The team's velocity chart is flat despite the growing backlog. The next sprint planning is tomorrow.
1. What is the highest-leverage intervention at tomorrow's planning, and why that one first?
Read the worked answer
The highest-leverage intervention is re-establishing the sprint boundary and honest commitment, because every other dysfunction is downstream of it. The data tell the story: a 42-point commitment against a 29-point delivery is a 31% overcommitment sustained across four sprints - that is not bad luck, it is a planning process that ignores its own history. Mid-sprint additions from the Product Owner make the commitment meaningless and directly cause the carryover.
At planning:
- Use observed velocity (29) as the planning input, not the aspirational 42, and make the basis explicit to the Product Owner.
- Agree the sprint goal and the rule that mid-sprint scope changes go to the backlog unless the team and PO trade something out - additions are swaps, not free.
- Surface the integration risk by making "integrate and demonstrate" part of the definition of done, so the separate-branch work becomes visible before it becomes a merge crisis.
Why first: without a stable, honestly-sized sprint, retrospective actions cannot be tested, velocity cannot stabilize, and the PO has no reason to change behavior. Fix the container before the contents.
2. The retrospective action items have no owners and never get done. How do you fix the retrospective itself?
Read the worked answer
An action list with no owners is a wish list. The fix is structural, not motivational:
- Cap the number of actions. Six unowned items become one or two owned ones. A retrospective that produces two completed improvements beats one that produces six abandoned ones.
- Assign a named owner and a due date to every action, and make the owner a volunteer rather than an assignee - ownership without commitment fails the same way.
- Make follow-through a standing agenda item. Open the next retrospective by reviewing the previous actions; if an action was not done, ask why as data, not as blame.
- Tie at least one action to an observable change (e.g., "definition of done includes integration" or "PO additions require a swap") so the team can see the effect in the next sprint.
The judgment being tested: retrospectives fail on follow-through, and follow-through is a process design problem. Adding more action items or more earnest discussion does not fix it; reducing and owning them does.