Scrum and the Agile Manifesto: how they fit

"We do Agile" and "we do Scrum" are often used as if they meant the same thing. They do not. One is a statement of values and the other is a definition of a working method. The relationship between them is close, and it is also easy to get wrong in both directions: teams that claim to be Agile because they hold Scrum meetings, and teams that follow Scrum's mechanics while ignoring everything the Manifesto asked for.

What the Manifesto says

The Agile Manifesto is a short document written in 2001 by a group of seventeen practitioners who represented several different lightweight methods. It states four values, each in the form "this over that": individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. The authors add that while there is value in the items on the right, they value the items on the left more.

Twelve principles sit behind the values. They cover early and continuous delivery, welcoming changing requirements, frequent delivery, daily collaboration between business people and developers, motivated individuals, face-to-face conversation, working software as the measure of progress, sustainable pace, technical excellence, simplicity, self-organising teams and regular reflection.

What it does not contain is as telling. There are no roles, no meetings, no artifacts, no timeboxes and no process. It is deliberately a set of preferences.

Where Scrum answers the Manifesto

Scrum gives specific, testable shapes to many of the principles. The mapping below is our reading, not a published rule, and it is useful because it shows which Scrum rule exists to protect which value.

Individuals and interactions. The Scrum Team has no sub-teams or hierarchies. The Developers decide how to turn items into Increments, and the Guide says no one else tells them. The Daily Scrum is a conversation among the people doing the work.

Working software over documentation. The Increment must be usable and meet the Definition of Done. The Sprint Review inspects the Increment, not a status report.

Customer collaboration. The Sprint Review is a working session with stakeholders. The Product Owner is one accountable person who represents stakeholder needs in the Product Backlog.

Responding to change. The Product Backlog is emergent. Scope can be clarified and renegotiated with the Product Owner during the Sprint. The Sprint Review adjusts the Product Backlog.

Principle by principle, the match is just as strong. Frequent delivery corresponds to the Sprint, no longer than a month. The preference for a sustainable pace corresponds to the Guide's remark that working in Sprints at a sustainable pace improves focus and consistency. Regular reflection is the Sprint Retrospective. Self-organising teams are the Guide's self-managing teams. Simplicity is echoed in the Guide's description of Scrum as lightweight and purposefully incomplete.

A worked example: reading a team against both

This is an illustrative situation. A team holds every Scrum event on time. It has a Product Owner who is a part-time proxy and who never speaks to users. The Definition of Done does not include testing. The Retrospective produces action items that are never started.

Against Scrum's rules, the Product Owner and the Definition of Done are weak, and the Retrospective lacks follow-through. Against the Manifesto's principles, the team has failed at close collaboration between business people and developers, at technical excellence and at regular reflection that changes behaviour. The same underlying faults show up in both mirrors, which is the point. Scrum's rules are a way of making the Manifesto's preferences hard to ignore.

The reverse also happens. A team with no recognisable Scrum may satisfy the Manifesto fully: small, collaborative, shipping often and reflecting weekly. That is Agile. It is not Scrum, and the Guide says that if you leave out elements, the result is not Scrum.

Why the distinction matters at work

The confusion has practical costs. When a manager says "we are Agile, so we do not need a plan", they are quoting the Manifesto badly, and the team ends up without a Product Goal. When a team says "we are doing Scrum, so the process is taken care of", they stop asking whether the working agreement serves the people in it. In the first case a value has been over-read. In the second a framework has been mistaken for a value.

It also matters for hiring and for training. A person who knows the Manifesto well but has not seen a Product Backlog at work can still contribute to a team's habits. A person who knows the Guide by heart but has never questioned a rule may follow it into a poor outcome. Both bodies of knowledge are needed, and the Manifesto is the one that asks you to keep thinking.

Where they diverge

Three differences are worth knowing.

First, the Manifesto describes values, Scrum describes rules. You can disagree with how Scrum applies a value and still hold the value. A Kanban team can honour the Manifesto without any Sprint.

Second, Scrum names accountabilities, the Manifesto names none. The Product Owner's accountability for ordering the backlog is not a Manifesto idea. It is a Scrum design choice.

Third, the Manifesto leaves out most of what practitioners do. User stories, story points and continuous integration are common in Agile teams, and neither the Manifesto nor the Scrum Guide requires them. The SBOK® Guide reproduces the Manifesto's four values and twelve principles in an overview chapter and then lists other agile methods, among them Lean Kanban and Extreme Programming, that share the Manifesto as a common root.

Common misreadings

• "Agile means no documentation." The Manifesto prefers working software and does not ban documents. The Definition of Done may well include documentation.
• "Agile means no plan." It prefers responding to change over following a plan. The Product Goal and Sprint Goal are plans.
• "Scrum is Agile, so anything we do in Scrum is Agile." A team can follow every rule mechanically and miss every value.
• "The Manifesto is a methodology." It does not say how to do anything.
• "Agile is for software only." The Manifesto is about software development, and the Guide notes Scrum is used well beyond it. See Scrum outside software.

How to practise it

A good habit is to hold your team's practices up against the four values once a quarter and ask which one a given practice protects. When none of them is, the practice may be habit. The simulator puts you in decisions where the values pull in different directions, such as a request for more documentation against a push to ship.