How to read the Scrum Guide without over-reading it

Many people have a strong opinion about Scrum and have never read the document that defines it. They know the daily stand-up, story points and a particular board tool, and they treat those as Scrum. Then they read the Guide and find that two of the three are not in it. The Guide is worth an hour of your time, and it rewards a particular way of reading.

What you are holding

The 2020 edition runs to roughly a dozen pages. Its opening section says that the Guide contains the definition of Scrum, that each element serves a specific purpose, and that changing the core design, leaving out elements or not following the rules covers up problems and limits the benefits. It also says that patterns, processes and insights that fit the framework may be found and applied, but that describing them is beyond its purpose because they are context sensitive and differ widely between uses.

That one paragraph sets your reading rules. The Guide is a definition, not a manual. It says what Scrum is. It does not say how to run every meeting, how to size work or which tool to buy.

The map of the document

The sections follow a sensible order, and it helps to hold them in your head as layers.

1. Definition and theory. Scrum is a lightweight framework for generating value through adaptive solutions to complex problems, founded on empiricism and lean thinking. Transparency, inspection and adaptation come next. See empirical process control for the long version.
2. Values. Commitment, focus, openness, respect and courage.
3. The Scrum Team. One Scrum Master, one Product Owner and Developers, with three accountabilities.
4. Events. The Sprint as a container, then Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective.
5. Artifacts. The Product Backlog, the Sprint Backlog and the Increment, each with a commitment.
6. End note. A short statement that Scrum is free, immutable as a framework and only works in its entirety.

Notice that the theory comes before the roles. The order is deliberate. The roles and events exist to make the theory work, and a reader who skips the first section ends up with a list of meetings and no reason for them.

Three kinds of sentence

The most useful skill is to sort the sentences you read into three kinds.

Rules. These say what is required. "The Product Owner is one person, not a committee." "Work cannot be considered part of an Increment unless it meets the Definition of Done." "Only the Product Owner has the authority to cancel the Sprint." If you remove a rule, you are no longer doing Scrum, whatever you call it.

Descriptions of intent. These explain what something is for, often with the word "purpose". "The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary." The purpose is binding in spirit, since a team that holds a Daily Scrum which does not do this has missed the point, but the Guide leaves the method to the Developers.

Examples and typical values. These use words like "often", "usually", "typically" and "for example". The Guide says a Scrum Team is typically ten or fewer people, and that Sprint Planning is "usually shorter" for shorter Sprints. These are guidance, and the sentence will tell you so if you read the adverb.

A worked example: one paragraph, three readings

Take this passage on the Daily Scrum: the Developers can select whatever structure and techniques they want, as long as the Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

A careless reader hears "whatever structure" and concludes anything goes. A habit-driven reader remembers the three-questions round-robin and concludes that is required. A careful reader sees two real requirements and one freedom. The requirements: focus on progress toward the Sprint Goal, and leave with an actionable plan for the next day. The freedom: the format. The three questions are one possible format, and earlier editions of the Guide included them, but the 2020 text does not require them.

You can do the same exercise for any section. Underline what must be true, circle what the purpose is, and mark what is left open.

What the Guide leaves out on purpose

The omissions are as important as the contents. The Guide does not define user stories, story points, velocity, burndown charts as required items, a Definition of Ready, roles above the Scrum Team, or how to scale. It mentions burn-downs, burn-ups and cumulative flows only to say that they are proven useful for forecasting but do not replace empiricism. It says nothing about sprint zero, hardening sprints or release trains.

This is not an oversight. The Guide says Scrum is purposefully incomplete, only defining the parts required to implement Scrum theory, and that it is built upon by the collective intelligence of the people using it. When you meet a practice that is not in the Guide, ask a simple question: does the Guide forbid it, support it or say nothing? Most of the time it says nothing, and the practice is a choice for the team.

Where the Guide changed

If you learned Scrum before 2020 you may remember different wording. The current edition describes a Scrum Team as a single unit with no separate development team inside it. It adds the Product Goal as the commitment of the Product Backlog. It says Sprint Planning has three topics, including why the Sprint is valuable. It describes teams as self-managing, and it dropped the three prescribed questions for the Daily Scrum. The Guide's History section also says it has evolved through small, functional updates since the first version in 2010.

Over-readings to watch for

• Treating every habit as a rule. If your team believes a Daily Scrum must be at nine, standing up, with three questions, check the Guide. It asks for the same time and place every day, to reduce complexity, and nothing more.
• Treating silence as permission to drop things. The Guide is explicit that leaving out elements covers up problems. A missing Retrospective is not a stylistic choice.
• Reading roles as a hierarchy. The Guide says there are no sub-teams or hierarchies in a Scrum Team.
• Taking "typically" as "exactly". Ten people is a typical ceiling, and a nudge to split a larger team, but it is not a law of nature.
• Quoting from memory. Terms change between editions. Check the text before citing a rule in a debate.

How to practise it

A good exercise is to read one section of the Guide, then run a small decision in the simulator and check which sentence you used. You find out quickly whether you were following the Guide or your habits.