IIBA CPOA study materials
IIBA CPOA study resources

The Backlog That Ate the Sprint

IIBA CPOA · Put your knowledge to work in context.

All case studies

The Backlog That Ate the Sprint

A five-person team building a health clinic scheduling app has a backlog of 250 items. Refinement consumes three hours weekly, yet only 20% of items meet the team's definition of ready. The product owner writes detailed functional specifications and treats stakeholder emails as requirements. Urgent requests arrive mid-sprint from the clinical operations director; 30% of committed points spill over each sprint. Sprint reviews focus on whether stories match the specification, not on whether clinics can schedule patients faster. The average story is 13 points and includes UI, API, and reporting work. The team has started four items at once in each of the last three sprints. The PO believes more refinement sessions will fix the problem. The team's sprint goal is usually a list of stories rather than a customer outcome.

1. Diagnose the root causes. Why is more refinement not the fix?

Read the worked answer

The root cause is not insufficient refinement; it is an oversized, unprioritized queue and a PO acting as a specification bottleneck. 250 items, 13-point stories, and four items in progress create long queues and partial work. Only 20% meet the Definition of Ready because readiness is being treated as a documentation gate, not as a shared understanding. Stakeholder emails become requirements because there is no intake and triage process, so the clinical operations director can inject work mid-sprint. Sprint reviews focus on specification compliance, which reinforces output thinking. The PO's detailed specs reduce team ownership and delay feedback. More refinement sessions would add batch size and cost without fixing flow. Diagnose with a value-stream map and a queue analysis: measure story cycle time, percentage of stories that enter mid-sprint, and rework. Then set a product goal around clinic scheduling outcomes, cap the active backlog, and make refinement a just-in-time conversation for the next one or two sprints.

2. How would you redesign refinement and story splitting? Be specific about practices and limits.

Read the worked answer

Redesign refinement as a short, focused conversation, not a weekly specification review. Limit the ready backlog to about two sprints of work and refine only the top items. Use example mapping or the three amigos-PO, developer, tester-to agree on rules and acceptance criteria. Split 13-point stories by workflow: for example, 'view available slots,' 'hold a slot,' and 'confirm appointment,' each independently demonstrable, rather than by UI/API/reporting layers. Apply INVEST and a lightweight Definition of Ready: clear outcome, acceptance examples, dependencies identified, and testable. Keep a spike only for genuine uncertainty. Stop writing detailed functional specifications; instead, write a problem statement and acceptance examples, and let the team design the solution. Measure the effect: percentage of stories completed within a sprint, refinement time, and story cycle time. If items still are not ready, reduce work in progress rather than adding more meetings.

3. How should the product owner handle mid-sprint requests from clinical operations while reducing spillover and work in progress?

Read the worked answer

Create a single intake and triage path for clinical operations. Distinguish emergencies-clinic cannot schedule patients-from urgent requests and normal demand. Give the director a weekly slot and a published SLA, and reserve a small capacity buffer for genuine emergencies. Any mid-sprint injection must name what comes out; the PO and director agree the trade-off. Enforce a work-in-progress limit of one or two items per person and stop starting new work before finishing. At the sprint review, show the outcome metric-time to schedule a patient, abandonment, or calls to the clinic-not just specification compliance. Track spillover, cycle time, and the percentage of unplanned work, and review with the director after four sprints. If urgent demand consistently exceeds the buffer, the issue is capacity or prioritization at the portfolio level, not team discipline. This makes the cost of interruption visible and protects the sprint goal without ignoring clinical operations.