Scrum Rules, Application and Organizational Context
Scrum Rules
The non-negotiables
Scrum's rules are few, but they are what make it Scrum. If you remove them, you are doing something else - possibly useful, but not the framework being tested.
Team rules: one Scrum Team, 10 or fewer, with no sub-teams or hierarchies; exactly one Product Owner; three accountabilities, not three teams.
Sprint rules: length is one month or less and consistent; no changes that endanger the Sprint Goal; quality does not decrease; scope may be clarified and renegotiated with the Product Owner; only the Product Owner may cancel, and only when the Sprint Goal becomes obsolete.
Event rules: all five events happen; timeboxes are maximums (Planning 8 hours, Daily 15 minutes, Review 4 hours, Retrospective 3 hours for a one-month Sprint); the Daily Scrum is held every working day; the Retrospective ends the Sprint.
Artifact rules: the Product Backlog is ordered and transparent; the Sprint Backlog is updated as more is learned; the Definition of Done is used whenever work is judged complete.
Accountability rules: the Product Owner maximizes value; the Scrum Master ensures the team's effectiveness and that events take place within their timeboxes; the Developers create the Increment; the Scrum Team is accountable for all product-related activities.
Traps
- "We skipped the Retrospective because we were busy" - the event is mandatory and its loss is a loss of adaptation.
- "We added a hardening Sprint" - not a Scrum construct.
- Treating refinement as a formal, timeboxed event in the framework.
- Believing the Daily Scrum may run long if the discussion is valuable.
- Believing a Sprint can be extended to finish work.
Rule of thumb
If a proposed practice needs a new role, event or artifact, it is a complement to Scrum - permitted, but never confused with the framework itself.
Application and Organizational Context
Deliberately incomplete
Scrum is intentionally incomplete: it defines only what is required to implement empiricism, and the organization supplies the rest. It is designed for complex work where requirements and approach emerge, and it says nothing about funding models, HR policy, architecture or tooling - those must be shaped to support it, not the reverse.
Serving beyond the team
The Scrum Master serves the organization: leading and coaching Scrum adoption, planning and advising implementations, helping stakeholders and employees understand empiricism, and removing barriers between stakeholders and the Scrum Team. The Product Owner serves the stakeholders by managing the Product Backlog and its transparency; the Developers serve each other.
Environment is the constraint
Organizations adopting Scrum usually must change funding cycles, performance measurement, governance and reporting that assume predictive planning. Common anti-patterns: a proxy Product Owner relaying decisions, a PMO approving Increments, component teams creating hand-offs, scaling by adding process instead of removing dependencies, and "transformation" programmes that leave incentives untouched.
Traps
- "Escalate to the PMO and follow the stage gates" - first ask whether the gate is an impediment the Scrum Master should help remove.
- "The team should produce a weekly percent-complete report" - the Sprint Review and the Increment are the transparency mechanisms; extra reporting is not transparency.
- "The Daily Scrum should be open so managers can get status" - the Daily Scrum serves the Developers; other channels can carry information outward.
- Treating Scrum as a complete methodology, or as a fix for problems caused by unclear goals or poor engineering.
Worked example
A team is required to report percent-complete against a fixed annual plan. The Scrum Master coaches the stakeholders on why an emerging Product Backlog cannot be forecast that way, and offers the Sprint Review plus the Product Goal as the honest substitute. The framework is not bent to fit the plan; the plan is changed to fit empiricism.
Rule of thumb
When the organization and Scrum conflict, the Scrum Master's job is to change the organization - not to bend the framework.