Ranking Teams by Velocity

Because story points are a relative, team-specific unit, not a currency, and velocity is a forecasting tool, not a performance metric.

• Points are anchored to each team's own reference stories and estimating history. Atlas's 42 and Beacon's 20 say nothing about relative productivity; they say something about how each team sized its own work.
• Calder reports ideal hours, a different unit entirely. Comparing hours to points has no meaning, and there is no legitimate conversion factor.
• Dividing by headcount does not fix this. Points estimate size and complexity, not effort per person, and the teams differ in domain complexity, technical debt, Definition of Done, and part-time availability.
• Beacon is three months old and has just onboarded two people, so its velocity is inherently unstable; Atlas is about to lose a member, which will change its throughput for reasons unrelated to effort.
• Ranking teams on velocity creates a direct incentive to inflate estimates and split stories to look fast. That destroys the honesty of the data the organization needs for forecasting, and it damages the safety that Scrum depends on.

What I would say to the Director: velocity answers 'how much can this team take on next Sprint', within that team. It cannot answer 'which team works hardest'. Using it for ranking converts a planning instrument into a political one, and the first casualty is accurate estimation.

Build the forecast from each team's own historical throughput, express it as a range, and re-forecast every Sprint.

• First, do not treat the 520 points as one pool. Because points are team-specific, allocate backlog items to teams and forecast each stream against that team's own throughput, then report the later date of the combined result.
• Use the observed distribution, not an average: Atlas has delivered 38 to 45, Beacon 18 to 24 but with only a short and unstable history. Derive a per-Sprint range, then a date range with an explicit confidence statement, rather than a single date.
• Adjust for known changes to the system, not by editing the historical data: Beacon's two new joiners will depress throughput during ramp-up; Atlas's departure will reduce capacity. State these as assumptions next to the forecast.
• Make the forecast visible as a burn-up chart of Done work against the projection, and update it at every Sprint Review.
• Reduce uncertainty where it is cheapest: refine and split large items, so the remaining work is better understood and the cone of uncertainty narrows as work is actually Done.
• Distinguish forecast from commitment in the steering meeting. The team can forecast a range with stated assumptions; it cannot promise a date on behalf of future Sprints it has not yet planned.

Why this matters: the Director is not wrong to want a date. The error is deriving a single fixed date from incomparable units, which produces false precision and sets the team up to fail.

Push back on both, with reasoning, and offer a workable alternative.

On standardising 1 point = 1 hour:

• This converts relative estimation into absolute estimation and loses what points are for: fast comparison of size and complexity across dissimilar work, without false precision.
• Teams will start estimating hours, sandbag, and argue about the conversion rather than about the work. The conversation about risk, uncertainty and complexity, which is the real value of estimation, disappears.

On velocity-linked bonuses:

• Any bonus tied to velocity growth rewards inflating estimates. Velocity will rise without more value being delivered, and the forecast data will become useless. This is a classic case of a measure being corrupted by becoming a target.
• It also punishes teams for improving their Definition of Done or paying down technical debt, both of which legitimately reduce velocity.

Offer instead:

• Flow and quality metrics for improvement, not ranking: throughput of Done items, cycle time, work in progress, lead time, escaped defects. Discuss them with the teams as a system, never as a league table.
• Outcome measures at product level: value delivered, customer usage, revenue or cost impact. If the Director needs cross-team visibility, this is the honest layer.
• Take this to the steering meeting jointly as Scrum Master and Product Owner, and propose a trial of the alternative measures with a review after three Sprints. The Scrum Master serves the organization here: the job is to explain the consequence, not just to refuse.