Scrum is the most widely used framework for agility in the world, and it fits in ten short pages. Not ten chapters. Ten pages, most of them about three quarters full. Strip out the title page and the table of contents and you can read the whole thing in under fifteen minutes. Most people who use it never have.
That is worth fixing, because a great deal of what goes wrong with Scrum goes wrong in the gap between what the guide says and what people assume it says.
Where it came from
In the 1980s a lot of people were building software, and the heavyweight project management that came before was too slow, too rule bound, and too process heavy to let them be nimble. Ken Schwaber and Jeff Sutherland spent that decade experimenting with a different way of building good products, and in 1995 they published what they had learned as a white paper.
Then they waited. Human beings have a remarkable ability to complicate the simplest thing, and it took until 2010 for the official Scrum Guide to appear. The current version is from 2020, and every revision since the first has made it shorter and less prescriptive. The three questions in the Daily Scrum, for example, are gone. The guide tells you what to do and why. It has never told you how.
More recently, two Certified Scrum Trainers, Bob Hartman and Tobias Mayer, produced the Simple Guide to Scrum, an even shorter restatement of the same framework that has since been translated into around twenty languages. Whether any certification body formally adopts it is still an open question. For now, treat it as a companion, not a replacement.
Roles became accountabilities, and that was the point
The 2020 guide stopped talking about roles and started talking about accountabilities. That sounds like a wording change. It ends an argument that derails a surprising number of teams.
“That is not my title.” “Is that the Scrum Master’s job or mine?” “We do not have a Product Owner, we have a business analyst.” None of that matters. The question is who is accountable for the things a Product Owner is accountable for, who is accountable for what the developers are accountable for, and who is accountable for what the Scrum Master is accountable for.
One way to hold all three in your head: the Product Owner is accountable for building the right thing. The developers are accountable for building the thing right. The Scrum Master is accountable for making sure the team can do that fast, with the roadblocks cleared and everyone working at the top of what they can do. Titles can be whatever the org chart needs them to be.
Can you do part of Scrum?
No. The guide describes itself as the definitive set of rules for the game, and the point of that phrasing is that the pieces only work together. Drop the Product Owner, skip the Sprint Retrospective, decide backlog refinement is not for you, and you may well have something useful. You do not have Scrum. Call it bananas. Bananas might work. But it is not Scrum, and calling it Scrum is how Scrum gets blamed for the results.
That is not a purity test. Any move an organization makes toward agility is worth making. It is a labelling rule, and labels matter because the next person to join the team will read the ten pages and expect to find them in practice.
Two kinds of dogma
Which raises the awkward word. Scrum practitioners have a reputation for dogmatism, and it is partly deserved. It helps to notice that the accusation gets used in two very different ways.
The first is projection. “You are being dogmatic” sometimes means “you are not letting me get away with my bad behavior.” You do have to coordinate the day. You do have to stop and inspect and adapt. How you do those things is entirely up to the team, but doing what you feel like and calling it agility is not agility. It is chaos. There has to be some framework, and nobody calls a budget review dogma.
The second kind is real. There are coaches who arrive with a playbook that says every organization must start by doing the same ten things, who insist on the perfect standing circle and the exact three questions, and who treat Scrum as the whole of agility rather than one good way to get there. They forget that not every organization can start from the same place, that culture and structure change what the first step should be, and that the first line of the manifesto is individuals and interactions. They are frustrating to follow, because someone has to undo the damage.
Both kinds exist. Which one you meet more often depends on where you sit.
Three artifacts, three commitments
The other 2020 change added a commitment to each artifact.
- The Product Backlog has a Product Goal. Think back to 2020, when OKRs were everywhere and Scrum had nothing that looked like one. The product goal is Scrum’s answer: a statement of the future state of the product that gives the backlog a single focus, the way a Sprint Goal focuses a Sprint but over a longer horizon. A useful way for a Product Owner to read it: when I work on the Product Backlog, I commit to delivering the product goal.
- The Sprint Backlog has a Sprint Goal, one objective for the Sprint that moves the product goal forward. This is the commitment teams most often skip, and the reason is usually honest. Many teams are not working on one product moving steadily forward. They have two features, a handful of tasks, and six bugs, a mixed bag of whatever the organization wants in the next two weeks. Writing a single goal over that is hard. It is also the point. If no single sentence describes what the Sprint is for, that is information about the Sprint.
- The Product Increment has a Definition of Done. This one works item by item. Whatever the work request is called, everyone knows the criteria it must meet before it can be considered finished and safely released. Acceptance criteria met, tests passing, deployable. Not one big judgement at the end of the Sprint, but a shared standard applied to every ticket.
Why there are five events, not four
Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective are obviously events. Why is the Sprint itself one?
Because an event in Scrum is not a meeting. A meeting can happen any time, for any length, with whoever turns up. An event has a recommended time, a recommended length, defined inputs, and defined outputs. The Sprint has all four. It is the container that holds the other events, the time box in which ideas become value, and the heartbeat of the whole framework. That is why it is counted.
The two events teams get wrong
Ask which event teams struggle with most and two answers come up again and again.
- The Sprint Retrospective, because it is boring, and it is boring because it is the same three questions every time. What went well, what did not, what will we change. Asked the same way every Sprint, people tune out, and it lands at the end of the Sprint when everyone is tired, so it becomes the event that gets sacrificed. Leadership then notices that nothing changes, decides the retrospective is a waste of an hour, and uses it as evidence that Scrum is a waste of meetings. Read any set of Scrum Master job postings and you will find this frustration spelled out. A retrospective is part team building and part inspection and adaptation. It should have energy, it should vary, and it should end with one thing the team will do differently. Not a laundry list. One thing, with a name next to it.
- The Daily Scrum, because it looks easy and so nobody takes it seriously. Teams treat it as a status report, discover that a status report does not fit in fifteen minutes, stretch it to an hour, and then complain about it. The fix starts with the Scrum Master stepping back. In a healthy Daily Scrum the Scrum Master is neither seen nor heard, taking notes at the edge about who to follow up with afterwards. If a team cannot self manage for fifteen minutes a day without being run, it is not self managing. It is dependent, and the dependency is the real problem. The three questions are gone from the guide for a reason. The only question that matters is what the most useful way is for this team to sync its work for the next twenty-four hours.
The whole framework in six words
Think big. Do small. Iterate often.
That is Scrum. Set a product goal that is worth reaching. Take one Sprint sized step toward it. Stop, look at what happened, and adjust before the next step. Everything else in the ten pages exists to make those six words possible, and none of it tells you how.
The how is yours!