Scrum As Written Vs Scrum As Practised

The Scrum Guide is short. You can read it properly in half an hour, and most people who run Scrum for a living have not done so in years. When they do, the common reaction is mild alarm, because a great deal of what their organisation calls Scrum is not in the document, and several of the things that are in the document have quietly gone missing.

This is not an argument for purism. Frameworks are not sacred texts and there is no prize for compliance. It is an argument about mechanism. Scrum is a small set of interlocking parts, and each part exists to force a specific behaviour that organisations do not produce by default. Remove the part and you remove the behaviour, but the meeting stays in the calendar, which makes the loss invisible. You end up paying the full ceremonial cost of the framework while receiving none of the control it was designed to provide.

So the useful question is not "are we doing Scrum correctly". It is "which mechanisms have we removed, and what were they holding up". What follows is what the framework actually says, what organisations actually do, and an honest ranking of which divergences cost money and which are harmless.

What the framework actually prescribes

Less than people think. Three accountabilities: Product Owner, Scrum Master, Developers. Five events: the Sprint itself as a container, plus Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Three artefacts, each with a commitment attached — the Product Backlog with its Product Goal, the Sprint Backlog with its Sprint Goal, and the Increment with its Definition of Done. Sprints of a month or less. That is substantially the whole of it.

The pairing of artefact and commitment is the part most often missed, and it is the structural heart of the framework. Each artefact is designed to be transparent, and each commitment is the thing that makes it possible to judge whether the artefact is in good order. A Product Backlog without a Product Goal is a list. A Sprint Backlog without a Sprint Goal is an allocation of tasks. An Increment without a Definition of Done is a claim.

It is at least as instructive to list what the Guide does not prescribe, given how much of it is treated as mandatory: story points, velocity, burndown charts, user stories, a fixed backlog refinement meeting, a two-week sprint specifically, three questions in the Daily Scrum, a full-time Scrum Master, a demo to stakeholders as a status report, or any estimation technique whatsoever. All of these are practices that grew up around Scrum. Several are useful. None are the framework, and treating them as the framework is how teams end up defending a ritual they cannot justify.

Set what the document says against what organisations typically run, and the pattern is consistent enough to tabulate.

As written	As practised
Sprint Goal is the commitment; the backlog serves it	Sprint is a list of unrelated tickets; the "goal" is written afterwards to describe them
Product Owner decides backlog order; the organisation respects that	Order is set by a steering committee; the PO relays decisions
Scrum Master is accountable for team effectiveness	Scrum Master books rooms, chases ticket hygiene and produces reports
Every Sprint produces a usable Increment	The increment is demonstrable but not releasable; release happens quarterly
Definition of Done is the organisation's quality standard	Each team has its own; several do not have one written down
Sprint Review is a working session that adapts the backlog	Sprint Review is a demo to stakeholders who do not change anything
Daily Scrum is the Developers' planning session for the day	Daily Scrum is a status round-robin performed for a manager
Developers select how much work to take on	Capacity is assigned; the team is asked to confirm it
Retrospective produces change	Retrospective produces a list
Sprint length one month or less	Two weeks, unexamined, for eight years

Not every row is equally expensive. The following five are the ones that reliably destroy value.

Divergence one: the sprint as a mini-waterfall

The most common structural failure. The team plans on Monday, analysis runs for two days, development for five, testing gets whatever remains, and everything arrives for verification in the final forty-eight hours. Work that fails testing rolls to the next sprint. The board shows a wall of items in the right-hand columns at the end of every cycle.

What has happened is that the phase structure of sequential delivery has been compressed into a fortnight rather than removed. The batch is smaller, which is a genuine improvement, but every queueing problem remains: work sits waiting between specialists, the integration risk is deferred to the end, and the cost of a defect found on day nine is still much higher than one found on day two. This is the mechanism explored in why busy teams are slow teams, operating inside a sprint boundary instead of across a release.

The tell is the shape of your throughput within the sprint. If nothing finishes before day seven, the sprint is not iterative — it is a very short waterfall with a demo attached.

The fix is not a better sprint plan. It is to make a single item flow to done before starting the next one, which means limiting work in progress within the sprint, pairing across specialisms, and treating "waiting for test" as the defect it is.

Divergence two: the Product Owner without authority

The Guide is unusually direct here: the Product Owner is one person, not a committee, and for that person to succeed the organisation must respect their decisions. In practice the role is frequently occupied by someone who holds the accountability and none of the authority — a coordinator who gathers requirements from stakeholders, arranges them into a backlog, and has no mandate to say no to any of them.

The consequence is predictable. Priority disputes are resolved by escalation rather than by decision, which means they are resolved slowly and by seniority rather than by value. The backlog becomes an accumulation of everything anyone has asked for. The team receives a list with no coherent thesis, and the Sprint Goal becomes impossible to write because there isn't one — there are eleven stakeholders' goals interleaved.

This is nearly always an organisational design problem rather than an individual capability problem, and it is treated at length in what a Product Owner is accountable for.

Divergence three: the Scrum Master as administrator

The Scrum Master is accountable for the effectiveness of the team — which the Guide frames in terms of causing the removal of impediments and changing the conditions the team works in, including conditions outside the team's boundary. In practice the role very often collapses into calendar management, ticket hygiene, note-taking and the production of status for people who have not been told they could look at the board themselves.

The administrative version is not merely a waste of a salary. It is actively harmful, because it converts the role into a buffer. Impediments get logged and managed rather than removed. The team stops expecting structural change. An organisation with a well-run impediment log and no impediments actually removed has institutionalised the problem.

This is the honest core of the Scrum Master value problem: the role is either about changing the system around the team or it is overhead, and most implementations quietly choose overhead because changing the system requires political capital the role has not been given.

Divergence four: no potentially releasable increment

The Increment is the artefact that makes empiricism possible; everything else in Scrum is arrangement around it. The requirement is that by the end of the Sprint something exists that meets the Definition of Done and could be released — whether or not the Product Owner chooses to release it.

Most implementations produce something demonstrable instead. It works in a shared environment, against representative data, with the hard parts stubbed, and it requires a subsequent hardening period, a regression cycle, a change advisory board and a release window before a customer could touch it. The gap between "demonstrable" and "releasable" is where all the remaining risk lives, and because it is invisible during the Sprint it accumulates silently until a release goes badly.

Run the arithmetic on your own organisation: if the Sprint is two weeks and the path from Sprint end to production is eight weeks, then your feedback loop is ten weeks and your sprint cadence is decorative. The only interventions that change this are the ones on the engineering side — trunk-based development, automated verification, and smaller deployable units.

Divergence five: commitment, misused

Older versions of Scrum used "commitment" to describe the set of backlog items selected for a Sprint, and the word did real damage. Teams were held to the list. Managers tracked completion against it. The predictable adaptations followed: pad the estimates, select less, split items to make the count look better, and never raise a risk mid-sprint because it threatens the number.

The current framing is considerably better. The team forecasts the work; the commitment is to the Sprint Goal. That distinction is the single most useful sentence in the document, because it makes mid-sprint adaptation legitimate. If the team discovers on day four that two of the selected items are unnecessary to achieve the goal, dropping them is success rather than failure. If achieving the goal requires work nobody anticipated, adding it is correct.

Organisations that still track item-level commitment have converted a learning mechanism into a performance-management instrument, with all the incentive corruption that implies. The same error applied to throughput gives you velocity as a performance metric.

Which divergences are harmless

Intellectual honesty requires admitting that a good deal of non-compliance costs nothing.

Fixed two-week sprints for a team whose work is well understood: fine, though worth revisiting. A part-time Scrum Master on a mature team: often correct, and the Guide does not require otherwise. Skipping the Daily Scrum on a day when the team is pairing all day in the same room: sensible. Using a flow board instead of a sprint backlog for operational work: frequently an improvement, and Kanban exists for exactly this. Dropping story points entirely in favour of counting right-sized items: usually an improvement, discussed in sprint planning that is not theatre.

The distinguishing question is whether the removed element was holding up a feedback loop or a decision right. Sprint length is a parameter. Product Owner authority is a mechanism. Losing a parameter costs you tuning; losing a mechanism costs you the framework.

What to do on Monday

Read the Guide, properly, with the team, in one sitting. It takes half an hour and it is the cheapest intervention available. Do it as a group so that disagreements surface in the room rather than afterwards.

Then take the ten rows in the table above and mark each one honestly against your own practice: as written, partially, or not at all. Do not fix anything yet. Instead, for each row marked "not at all", write one sentence explaining what that element was meant to produce and what currently produces it instead. Several will have an acceptable substitute. The ones with no substitute are your actual backlog.

Pick the highest-scoring one that sits inside your control and change it for four sprints. In most organisations that is the Sprint Goal — stop selecting items first and writing the goal afterwards, and instead agree the goal first and select only the work that serves it. It is a small change to the order of a single meeting and it is the fastest way to find out whether your sprint has a thesis or just a list.