The team completed 42 points last sprint. The target is 45. Leadership wants to understand the gap.
The retrospective focuses on what slowed the team down. Nobody asks whether the 42 points moved the product forward.
The number is the conversation. The direction is not. Velocity became the metric, and the metric became the mission.
⸻
The Points Treadmill
Story points were never meant to measure output. They were designed to measure relative complexity. A 5-point story is roughly twice as complex as a 3-point story, within the context of that specific team.
But the system cannot resist turning a relative measure into an absolute target. Once velocity is tracked, it becomes a performance metric. Once it is a performance metric, it is optimized.
Teams learn to inflate estimates. A story that was a 3 becomes a 5, because higher points produce higher velocity without additional work. The chart goes up. The product stands still. Everyone is satisfied except the customer.
⸻
The Burndown Pressure
The sprint burndown chart creates a visible expectation. Stories should close at a steady rate. The line should descend smoothly toward zero.
In practice, engineering work does not close linearly. Discovery happens mid-sprint. Requirements change. Dependencies surface. The chart flatlines for three days, then drops sharply as everything closes on the last day.
The team knows this pattern. But the chart makes the flatline visible to management, creating anxiety that manifests as standups about standups. The team responds by breaking stories into smaller pieces that close faster, producing a smoother chart without changing the actual amount of work completed.
The chart looks healthy. The relationship between the chart and reality has dissolved.
⸻
The Feature Counting Fallacy
When velocity is the primary metric, the system prioritizes stories that can be counted over work that matters but cannot be measured.
Refactoring does not have story points. Mentoring does not have story points. Investigating a production anomaly that might become an outage does not have story points. These activities are invisible to the velocity metric, so the system deprioritizes them.
The team ships features. The codebase degrades. The engineer who spent Saturday preventing a cascading failure opens Monday's sprint board. The work was never ticketed. Her weekend did not happen.
⸻
The Speed Question
Velocity answers "How much did we do?" It never answers "Did it matter?"
The second question is harder. It requires judgment, context, and a willingness to admit that some completed work was wasted. The system avoids this question because the answer might be uncomfortable.
Forty-five points shipped. None of them moved a business metric. That was not productivity. That was motion.
End.