Velocity Used as a Performance Target
A Scrum Master is assigned to a team of five developers at a fintech company. Six months ago the head of engineering introduced a dashboard that publishes each team's velocity and a 'commitment reliability' score, calculated as completed points divided by points selected at Sprint Planning. Teams below 90% reliability are flagged red and discussed in a weekly managers' meeting. The team's behaviour has changed: they now select only items they are certain to finish, routinely splitting stories into very small pieces, and refusing to take on anything with technical uncertainty. Two senior developers have privately told the Scrum Master they no longer raise risks at Planning because 'it makes our number look bad'. The Product Owner complains that hard, valuable items never get picked up.
1. Explain why this dashboard is producing these behaviours, referring to Scrum's commitments and the purpose of the artifacts.
Read the worked answer
The dashboard converts a forecasting and transparency tool into a target, and the team is rationally optimising for the target. Velocity is an emergent measure of how much work a team completes per Sprint; it is useful for the team's own forecasting and for detecting trends, but it is not a commitment and was never designed to compare teams or individuals.
The Sprint Backlog's commitment is the Sprint Goal, not a point total. By scoring 'commitment reliability' against selected points, the organisation has invented a commitment Scrum does not make, then penalised teams for not meeting it. The Sprint Goal is meant to give the team a coherent objective and the flexibility to negotiate scope with the Product Owner as they learn. That flexibility is exactly what the dashboard punishes.
The behaviours follow predictably. Selecting only certain items is risk avoidance, not improved predictability. Splitting into tiny pieces inflates the count of completed items while reducing meaningful value. Avoiding uncertain work removes the learning that Sprint Goals exist to encourage. Not raising risks at Planning is the most serious symptom: transparency has become personally costly, so the team hides information, which degrades the empirical process the artifacts are supposed to support. The Product Owner's complaint confirms the outcome: valuable, uncertain work is systematically starved.
2. What should the Scrum Master do, and what should they avoid doing?
Read the worked answer
Avoid: coaching the team to game the metric better, negotiating a softer target, or becoming the team's advocate for a lower number. All of these accept the premise that velocity should be a management target and leave the underlying system intact. Also avoid publicly challenging the head of engineering in a way that makes the team's Scrum Master the story.
Do:
Make the consequences visible with evidence. Collect the specific observations: the two developers' reluctance to raise risks, the shift to low-uncertainty items, the Product Owner's inability to get valuable work started. Present these to the head of engineering as the dashboard's actual effects, not as a complaint about pressure.
Reframe the purpose. Propose that velocity be used by the team for forecasting and by leadership only in aggregate, never to rank teams or flag individuals. Suggest replacing 'commitment reliability' with a Sprint Goal achievement conversation, and if a reliability measure is required, base it on whether the Sprint Goal was met and what was learned, not on point ratios.
Re-establish safety at Planning. Coach the team to raise risks explicitly and coach the Product Owner to treat raised risks as useful information. Agree with the Product Owner that uncertain items will be deliberately included so the team can learn.
Work through the Retrospective. Let the team name the behaviour change themselves and choose one experiment, such as selecting one high-uncertainty item per Sprint.
Escalate if needed. If the dashboard persists, the Scrum Master's responsibility is to keep raising the impediment through appropriate channels, since removing organisational impediments is core to the role.