The Velocity Mandate
A Scrum Master joins a 40-person product group three sprints into a new quarterly planning model. The VP of Engineering has introduced a target: each of the five teams must raise its average velocity by 15% per quarter, and velocity is reported on a shared dashboard alongside a team ranking. Two teams have started splitting stories into smaller pieces without changing scope, and one team's Product Owner now accepts work mid-sprint to keep the number moving. In a retrospective, engineers describe the dashboard as 'the real boss.' A senior developer privately tells the Scrum Master that the team stopped refactoring two sprints ago because refactoring 'doesn't show up as points.' The Scrum Master has no authority over the VP's dashboard and has been told the metric is 'non-negotiable' by the group's director.
1. Using Scrum theory and principles, diagnose what is happening. Which empirical pillar is most directly undermined, and what is the mechanism?
Read the worked answer
The core problem is that velocity has been turned into a target rather than a forecast. Scrum rests on empiricism: transparency, inspection, and adaptation. The pillar most directly damaged is transparency.
Mechanism:
- Velocity is only meaningful as a relative planning aid derived from the Definition of Done. Once it is compared across teams and used to rank, it stops being a transparent signal of completed work.
- Story-point splitting without scope change inflates the number while the underlying work is unchanged - the artifact (Increment/points) no longer transparently reflects reality.
- Refactoring disappearing from the number means the Definition of Done is quietly eroding; the increment is less 'done' than the dashboard implies.
- Accepting mid-sprint work destroys the Sprint Goal as a focus mechanism, so inspection at the Sprint Review compares against a moving target.
The Scrum Master should name this clearly: the dashboard is producing false transparency, and inspection on false transparency leads to bad adaptation (gaming, hidden technical debt). This is a Scrum theory failure, not a team-discipline failure.
2. The Scrum Master cannot change the VP's dashboard. What concrete actions should the Scrum Master take, in order, and what is the intended outcome of each?
Read the worked answer
Work the influence available, not the authority unavailable.
- Make the cost visible, not the argument. Bring data to the group's Scrum Masters and the director: trend of escaped defects, time spent on unplanned work, and the two sprints of deferred refactoring. Outcome: the conversation shifts from 'is the metric fair' to 'what is this metric costing us.'
- Protect the Definition of Done explicitly. Ask each team to state in its DoD that refactoring and quality work are required for 'Done.' Outcome: work that the dashboard ignores becomes non-negotiable in the increment, and velocity reflects real completion.
- Re-anchor the Sprint Goal. Coach the team whose PO accepts mid-sprint work to refuse changes that endanger the Sprint Goal and to negotiate scope instead. Outcome: restores focus and makes the Review a real inspection.
- Offer the VP a better instrument. Propose that the dashboard report outcome measures (released value, predictability, cycle time) alongside velocity, and stop cross-team ranking. Outcome: gives the VP a face-saving path to a metric that doesn't reward gaming.
- Escalate once, factually. If the director insists, put the risks in writing to the director with the evidence from step 1. Outcome: the Scrum Master has discharged the servant-leader duty to remove impediments and protect the team, without becoming an adversary.
Avoid: telling teams to 'just ignore' the dashboard (removes transparency), or unilaterally refusing to report (creates a political fight the SM will lose).
3. A team member asks: 'If velocity is misused, should we stop estimating in points?' How should the Scrum Master answer?
Read the worked answer
No - the problem is the use, not the unit. Points are a legitimate relative-sizing tool that helps a team forecast how much Product Backlog it can take into a Sprint. Removing them because a manager misuses them treats a symptom.
The Scrum Master should explain:
- Estimation serves the team's own forecasting and the Sprint Planning conversation; it was never intended as a performance measure.
- The fix is to change how the number is consumed (see the dashboard actions), and to keep the number honest via a shared Definition of Done.
- If the team genuinely finds points unhelpful, that is a separate, legitimate experiment - but it should be chosen for the team's benefit, not as a defensive reaction to a manager.
This keeps the team anchored in Scrum theory (empirical planning) rather than in a workaround.