Carryover and work-in-progress in a payments squad
A payments squad of eight people runs two-week sprints. Average velocity is 42 story points, but 35% of committed points carry over each sprint. The board often shows 18 items in progress, while the team has one QA specialist who also handles production incidents. Stories are large, usually 8–13 points, and several depend on a platform team that delivers on its own schedule. Sprint reviews are frequently cancelled because “nothing is demo-ready.” The Scrum Master responds by adding more stories to the next sprint to “increase throughput,” and the product owner complains that predictability is getting worse. The team says it is “doing Agile” because it holds daily stand-ups, planning, and retrospectives. You are brought in to improve delivery without simply telling people to work harder.
1. Diagnose the situation. What is the most likely system problem, and what evidence would you examine?
Read the worked answer
The symptom is not low effort; it is too much work in progress combined with large batch sizes, a QA bottleneck, and external dependencies. Eighteen items in progress for eight people means context switching and hidden partial work. A single QA specialist who also handles incidents creates a constrained queue; work piles up before verification and carries over. Large 8–13 point stories increase uncertainty and delay feedback. Cancelled reviews are a leading indicator that “done” is unclear or that integration happens late. I would examine a cumulative flow diagram, cycle time and blocked time, the age of in-progress items, carryover by story size, QA queue length, incident load, and the definition of done. I would also check whether dependencies on the platform team are known at planning or discovered mid-sprint. This evidence separates a flow problem from a commitment problem and avoids blaming velocity.
2. Design a sequenced set of interventions for the next four weeks. Which Agile practices would you introduce, and why in that order?
Read the worked answer
Week 1: make the work visible and limit it. Set explicit WIP limits by column, including a QA queue limit, and stop starting new work when a limit is hit. This exposes the bottleneck before changing planning. Week 2: reduce batch size. Work with the product owner and team to split 8–13 point stories into vertical slices with clear acceptance criteria and demoable outcomes. Smaller items shorten feedback time and reduce carryover risk. Week 3: address verification capacity. Move a second team member into QA pairing or automation for the highest-risk areas, and define a done policy that includes verification. This is not a permanent role change; it is a capacity experiment. Week 4: make dependencies and reviews explicit. Add a dependency check at planning, agree a weekly platform sync, and reinstate a short review with at least one demoable slice. Sequence matters: limiting WIP first exposes the real constraint; splitting without limits can still overload QA.
3. What measures and risks would you track, and how would you avoid gaming?
Read the worked answer
Track cycle time, 85th percentile cycle time, carryover percentage, blocked time, QA queue age, review demo frequency, and escaped defects. Use these as trend indicators, not individual targets. Avoid measuring story points per person or comparing velocity across teams; that invites point inflation and story splitting that does not reduce risk. Watch for WIP limits being bypassed through “expedite” lanes, QA becoming a permanent gate, and reviews becoming show-and-tell rather than feedback. Check whether carryover falls because work is smaller and more finished, or because the team commits to less and hides risk. Review the data with the team weekly and ask which practice change produced the effect. If QA load remains high after four weeks, revisit the capacity model and incident rotation rather than pushing the team to commit to more.