When Story Points Become a League Table
Four teams at Corvus Software, 52 people, deliver a B2B billing platform. Leadership's monthly dashboard ranks teams by story points per sprint: Team A reports 45, Team B 39, Team C 31, Team D 22. After the ranking began, Team D's estimates inflated, two senior developers stopped pairing with juniors because 'it slows the points,' and Team A split a reporting feature into 11 separately demoable stories that share one database migration. Release predictability fell from 85% to 62% in two quarters; cross-team defect fixes now wait an average of nine days. The VP of engineering asks you to 'fix the metrics' before the next board review and wants a single number per team that is comparable and motivating.
1. Diagnose what the story-point ranking is causing. Use specific evidence from the setup.
Read the worked answer
The ranking converts a relative estimation unit into a productivity score, so it rewards inflation and fragmentation. Team D's estimates inflated after ranking; Team A split one reporting feature into 11 stories sharing a database migration; seniors stopped pairing because pairing 'slows the points.' Those are predictable responses to a measure used for comparison rather than forecasting. Release predictability fell from 85% to 62%, and cross-team fixes wait nine days - the ranking optimizes local point totals at the expense of flow and collaboration.
DA's principles point the other way: optimize flow, be transparent, and measure outcomes. Story points were designed for team-level forecasting, not cross-team productivity. The VP's request for a comparable single number will reproduce the same behavior unless the purpose changes from ranking to improving.
2. Propose a replacement measurement set for the board review. Explain how each measure drives a different behavior.
Read the worked answer
Replace the ranking with a small balanced set: (1) release predictability - percentage of committed scope delivered by the committed date; this rewards honest commitments rather than point volume. (2) End-to-end cycle time from ready to released; this exposes queueing and encourages smaller batches, not smaller stories for point inflation. (3) Escaped defect rate per release; this discourages passing work downstream. (4) Cross-team collaboration indicator - for example, percentage of cross-team defects resolved within an agreed service level; this makes the nine-day wait visible. Report by value stream or product, not by team rank. Add a qualitative improvement narrative: one experiment per team and what was learned.
Pair the measures so they cannot be gamed in isolation: cycle time plus escaped defects prevents 'go faster by cutting testing.' Present trends over three to six months, not a monthly league table.
3. The VP insists on one comparable number per team. What do you offer, and what risk do you flag?
Read the worked answer
Offer a single 'flow health' index only if it is used for improvement dialogue, never for ranking or incentives. Build it from normalized, team-owned inputs: predictability, cycle-time trend, and escaped defects, with explicit weights agreed in advance. Flag two risks: Goodhart's law - once the index becomes a target, teams will optimize the index; and loss of diagnostic detail - a composite hides which constraint to fix.
Safer alternative: one number for the board that is not per team - overall release predictability for the product - with a drill-down the board reviews quarterly. If the VP still wants per-team comparison, propose a peer-review format where teams present their own trend and ask for help, not a league table. Document the decision and revisit after two quarters using the evidence: whether collaboration and predictability improved.