COPR ACP study materials
COPR ACP study resources

The Velocity Trap in a Regulated Claims Team

COPR ACP · Put your knowledge to work in context.

All case studies

The Velocity Trap in a Regulated Claims Team

A 14-person insurance claims squad has run six two-week sprints. Their velocity chart reads 31, 44, 38, 52, 47, 61 story points. The product owner celebrated the trend and committed 64 points for the next sprint. The Scrum Master notices that the team's definition of done quietly lost its peer-review and regression-test steps in sprint three, and two of the highest-point stories shipped with defects found in production. Meanwhile the compliance team requires an audit trail for every claims-decision change, and the squad has been logging that manually at sprint end. The team works across two time zones with a four-hour overlap. The organization's leadership has just announced a quarterly OKR tying bonuses to "points delivered per sprint."

1. As the Scrum Master, how should you respond to the velocity trend and the 64-point commitment?

Read the worked answer

The rising numbers are not evidence of improved delivery; they are confounded by a weakened definition of done. Before any planning decision, I would separate the two signals.

First, I would make the definition-of-done erosion visible without blame. Pull the sprint-three change record, list exactly which quality steps were dropped, and ask the team what pressure caused it. The four-hour overlap and the manual audit logging are plausible contributors, so the conversation should start from system conditions, not individual performance.

Second, I would challenge the 64-point commitment on its merits. The last three sprints averaged about 53 points, and the highest figure was produced under a degraded definition of done. Committing 64 assumes the trend is real capacity, which is an unsafe extrapolation from six data points. I would propose a forecast range, not a single number, and re-baseline only after two sprints with the restored definition of done.

Third, I would escalate the incentive design. Bonuses tied to points delivered per sprint reward exactly the behavior that produced the defect leakage. I would raise this to leadership with the defect data and propose outcome-based measures such as escaped-defect rate and cycle time instead.

2. The compliance audit trail is being reconstructed manually at sprint end. What is the agile-appropriate remedy, and what does it have to do with the velocity problem?

Read the worked answer

Manual reconstruction at sprint end is a batch process bolted onto an iterative workflow, and it is a symptom of the same underlying issue: work that should be inside the definition of done is being deferred to a cleanup phase. Deferred compliance work is deferred quality work, and it consumes capacity unpredictably, which distorts velocity.

The remedy is to move auditability into the flow. Options include automating the change log at the point of merge, adding an audit-trail check to the pull-request template, and writing an acceptance criterion on each claims-decision story that the required record exists. If automation is not feasible this quarter, the team should at minimum estimate the logging as part of each story rather than absorbing it as unplanned sprint-end work.

I would also add a compliance representative to refinement so the audit requirement is understood before stories are sized. Once the trail is generated continuously, the sprint-end batch disappears, capacity becomes more predictable, and the velocity figures start to mean something again. The two problems share one root cause and should be solved together, not tracked as separate workstreams.

3. Leadership insists the OKR stays. What do you do?

Read the worked answer

I would not silently accept a metric that actively harms delivery, nor would I frame it as the team refusing accountability. I would bring evidence and an alternative.

The evidence: point inflation is occurring, definition of done was weakened under commitment pressure, and two production defects trace to the missing regression step. A bonus tied to points per sprint converts a planning tool into a target, and the team is already responding rationally to that incentive.

The alternative: propose outcome measures the team can influence and leadership cares about, such as escaped-defect rate, lead time from claim decision to audit-ready record, and percentage of committed scope delivered without quality exceptions. Offer to report these weekly so leadership keeps visibility.

I would also protect the team in the interim by decoupling sprint commitments from the bonus conversation, for example by reporting a forecast range and explaining variance rather than defending a single number. If leadership overrides, I would document the risk in writing and continue coaching the team to protect the definition of done regardless of the incentive.