Velocity Is Falling and Nobody Owes the Retro Actions
Meridian Software runs two-week sprints with a seven-person Scrum team. Velocity over the last four sprints: 46, 41, 38, 34 points. The product owner adds "urgent" items mid-sprint almost every sprint, and two stories have carried over three sprints in a row. The team demos a feature to stakeholders and it is rejected because "it doesn't do what we expected" - acceptance criteria were never written. QA happens in the last three days of each sprint, and defects regularly spill into the next sprint. Retrospectives produce a long list of actions that nobody owns. The team says it is "being asked to go faster."
1. Diagnose the velocity trend. What data would you examine, and what would you deliberately not do?
Read the worked answer
The trend is a symptom; chase the cause, and never turn velocity into a target.
First, check comparability before concluding anything: did team membership change? Was a sprint hit by holidays or a production-support surge? Did the team change its point scale? If the baseline moved, the slope is partly an artifact.
Then examine:
- Throughput and cycle time (stories completed, days from start to done) - more reliable than points.
- Carryover count and cumulative flow - the two stalled stories have been counted in more than one sprint, which likely inflates points "in progress" and masks the real rate.
- Unplanned work - points added mid-sprint each sprint; that is scope, not capacity, and it explains the decline.
- WIP and the QA bottleneck - if QA only runs in the last three days, work piles up and nothing finishes until the end; the team is busy, not done.
Deliberately avoid: treating 46 as the standard the team must return to, comparing velocity across teams, or promising the sponsor more output. Velocity is a forecasting input, so a stable 34 is a planning fact, not a failure. Say it out loud: "Our forecast is ~34 points per sprint; the decline traces to mid-sprint injections and a finishing bottleneck, and here is how we are fixing both."
2. How should the team handle the product owner's mid-sprint additions without damaging the relationship?
Read the worked answer
Protect the sprint goal, then negotiate trade - never just say no.
The sprint goal is the team's commitment; a sprint backlog that changes daily means nothing can be finished and the burn-down becomes fiction. But the PO's urgency is usually real, so the response is a trade, not a refusal.
- Make the cost visible. Track injected points per sprint. Show the PO: "Sprint 4 delivered 34 points versus a plan of 41; 9 points were added after commitment and two stories did not finish."
- Offer the swap. "We can take this 5-point item if we drop the 5-point report export to next sprint. Which do you want?" Equal-size trade keeps the sprint whole.
- Defer with a date. Small or future-appropriate items go to the top of the backlog and get refined for the next sprint - a real commitment, not a brush-off.
- Escalate the pattern, not the incident. At refinement and sprint review, agree an explicit rule: sprint scope is fixed once the goal is set; genuinely urgent work is handled by the PO cancelling the sprint deliberately, which is rare and costly, or by reserving a small capacity slice if unplanned work is genuinely business-as-usual.
- Come with data. Scrum Masters change behavior with flow metrics and predictability numbers, not appeals to process purity. "Our release forecast is +/- 6 points when injections happen, and +/- 1 when they don't" is the sentence that ends the pattern.
3. The demo was rejected for missing expectations and QA is bolted on at the end. What do you change, and how do you make retro actions actually stick?
Read the worked answer
Fix "done" first - most of the other symptoms follow from an undefined finish line.
Acceptance criteria. Every story gets explicit criteria before development, ideally in Given/When/Then form. Example: "Given a registered user with a saved card, when they select one-click checkout, then the order is placed in under 3 seconds and a confirmation email is sent." The PO writes them; the team confirms they are testable during refinement. If a stakeholder can reject a demo, their expectations were knowable earlier - write them down.
Definition of Done. Agree a team-level DoD, e.g.: code reviewed; unit and automated regression tests passing; no open P1/P2 defects; deployed to staging; PO has accepted against criteria; docs updated. Nothing counts as done until it meets all of it.
Move QA left. Pair developer and QA on the story rather than at the end, automate regression so the last three days are not a test marathon, and swarm on unfinished stories instead of starting new ones. Track it with carryover count and cycle time - a drop in carryover is the proof.
Make retros stick. Cap each retro at one or two actions, each with a named owner and a date, written into the backlog as real work with a visible card on the board, and reviewed as the first agenda item of the next retro. Rotate ownership rather than defaulting to the Scrum Master. Then measure whether the action changed anything - an unmeasured action list is how a team ends up with fifteen good intentions and a falling velocity.