Twenty-Two Teams, Twenty-Two Definitions of Done
A bank runs 'Scrum' across 22 teams contributing to one internet banking product. Each team has its own Product Owner, its own backlog and its own Definition of Done. Integration happens quarterly, and the last two releases were rolled back. A governance board requires each Scrum Master to sign off any change to Sprint scope and to approve any amendment to a Sprint Goal. HR ties 40% of each Developer's bonus to 'individual velocity'. Last month one team cancelled a Sprint mid-flight without telling the Product Owner's stakeholders; another team extended its Sprint by a week to finish testing.
1. Sort these practices into (a) direct breaches of Scrum rules and (b) organisational impediments the Scrum Master must surface. Justify each placement.
Read the worked answer
(a) Direct breaches of Scrum rules
- Scrum Master signing off Sprint scope changes. The Developers own the Sprint Backlog; the Scrum Master is accountable for the team's effectiveness, not for approving work. This contradicts self-management outright.
- Scrum Master approving Sprint Goal amendments. Related but distinct: scope may be clarified and renegotiated with the Product Owner as more is learned, without affecting the Sprint Goal. If the Sprint Goal genuinely becomes obsolete, the answer is cancellation by the Product Owner - not a governance amendment.
- Extending the Sprint by a week. Timeboxes are fixed; a Sprint is a container of fixed length. Extension destroys the cadence that makes inspection comparable Sprint to Sprint.
- A team cancelling a Sprint. Only the Product Owner can cancel, and only when the Sprint Goal becomes obsolete. A team cannot cancel, and stakeholders must always be informed when a Sprint is cancelled.
(b) Impediments the Scrum Master serves the organisation to fix
- 22 teams, one product, 22 Definitions of Done. Not a rule breach by any individual, but it guarantees that no one can say what 'Done' means for the product - and quarterly integration plus two rollbacks is the receipt.
- 22 Product Owners for one product. Scrum assumes one Product Owner per product, accountable for ordering one Product Backlog; delegation is allowed, divided accountability is not.
- Bonus tied to individual velocity. This manufactures the incentive to inflate estimates and to optimise locally, which is the opposite of an empirical, team-level forecast.
Distinguishing the two categories matters: the Scrum Master can refuse to sign off and coach through it. The 22-DoD structure needs leaders outside the team to change it.
2. Which single change would most reduce the rollback rate, and how do you argue for it with people who own the current structure?
Read the worked answer
One shared Definition of Done for the product, enforced at every team's Increment - underpinned by one Product Backlog and one Product Goal for the internet banking product.
Why this one:
- Quarterly integration fails because integration is not in anyone's Definition of Done. Each team's 'Done' stops at its own boundary, so the product-level increment is assembled four times a year by people who did not build it.
- Two rollbacks are the empirical evidence. You do not need a theory argument; you need the last two release post-mortems and a question: at what point in the Sprint did any team own an integrated increment?
- A shared Definition of Done is explicitly required when multiple teams work on the same product - they must mutually define it. It is not a new process; it is the minimum Scrum already asks for.
How to argue it where you have no authority:
- Lead with the cost they already pay - rollback remediation, hardening effort, integration Sprint overhead - not with the Scrum Guide.
- Propose a bounded experiment, not a 22-team reorganisation: two teams define a joint Definition of Done including integration, for one quarter, and measure rollbacks.
- Keep the governance board's need intact. They want predictability. A joint Definition of Done delivers it; 22 private standards cannot.
What I would not do is argue that the structure is non-compliant and stop there. The Scrum Master serves the organisation; being right without moving anyone changes nothing.
3. A Developer asks whether the team should adjust its velocity figures so the bonus is distributed fairly across the group. How should the Scrum Master respond?
Read the worked answer
Firmly and without moralising, because the request is a symptom rather than a character flaw.
On the direct question: no. Adjusting reported figures is a transparency failure of exactly the kind that makes the artefact useless. Once the number is negotiated for bonus purposes it cannot be used for forecasting, and the team loses the only empirical signal it has. The team should not be asked to choose between an honest backlog and their pay.
Reframe what has actually been asked for. The Developer is describing real distress: a scheme that punishes collaboration. The Scrum Master's job is to take that to the people who can change it.
What to do next:
- Make the impediment visible with evidence - Retrospective themes about hoarding work or avoiding pairing, and any correlation between the velocity bonus and the release failures.
- Propose measures that reward the outcome the bank actually wants - percentage of increments meeting the shared Definition of Done, time from start to Done, escaped defects, customer-facing outcomes. These are team-level and harder to game.
- Protect the Developers from the conflict while it is unresolved: the Scrum Master raises it with HR and leadership, and does not leave individual Developers to absorb it.
Important limit: the Scrum Master cannot change a bonus scheme. They can insist that the team's artefacts stay truthful, and they can refuse to let the scheme quietly corrupt them. Escalating the impediment is the accountability; fixing HR policy is someone else's.