Scrum vs Agile: Is Scrum Part of Agile, and What Differs?

A common myth says Scrum and Agile are two names for the same thing, so a team that "does Scrum" has nothing more to learn about Agile. They are different kinds of thing. Agile is a set of values and principles, written down in 2001, that says what good software work should favour. Scrum is a framework, defined in the Scrum Guide, that says exactly which roles, events and artifacts a team uses. Scrum is one way to act on Agile, and only one.

The rest of this article keeps that distinction sharp. It explains what each term covers, sets them side by side, shows where the idea "Scrum is a subset of Agile" helps and where it misleads, and ends with what it means if you want a credential such as Scrum.org's PSM I. Scrum facts come from the 2020 Scrum Guide, and the Agile history from the Manifesto as summarised on Wikipedia.

Is Scrum simply another name for Agile?

No, and the easiest way to see why is to ask what each one lets you do on Monday morning. Agile cannot tell you what to do on Monday morning. Its four values and twelve principles say things such as "respond to change over following a plan" and "working software is the primary measure of progress." Nobody can run a team by reading them, because they never say how often to meet, who orders the work, or when a release is ready.

Scrum can tell you. It says the work sits in a Product Backlog ordered by one Product Owner, the team plans a Sprint, meets for fifteen minutes each working day, shows the result at a Sprint Review and then looks at its own habits in a Retrospective. A team can follow every one of those rules and still behave in ways the Agile values would reject, for instance by treating the Daily Scrum as a status report to a manager. The framework is a means; the values are what the means should serve.

That is also why the question "Scrum or Agile?" is badly formed. It is like asking "recipe or cooking?" The better questions are "Which Agile approach fits this work?" and "Are we using it in the spirit of the values?" The answers vary by team, product and organisation, which is exactly what Agile expects.

It also explains the search habit behind the question. People type "scrum vs agile" or "is scrum part of agile" because job adverts, courses and certificates use the two words as if they were interchangeable. They are not, and an interviewer who asks you to explain the difference is usually listening for exactly one idea: one is a mindset with a manifesto, the other is a prescribed framework with rules.

What is Agile, if it is not a method?

Agile software development is an umbrella term. In 2001 seventeen software practitioners met at a resort in Snowbird, Utah to find common ground between lightweight approaches such as Extreme Programming, Scrum and Adaptive Software Development. They agreed on the Manifesto for Agile Software Development, which values:

• individuals and interactions over processes and tools;
• working software over comprehensive documentation;
• customer collaboration over contract negotiation;
• responding to change over following a plan.

The Manifesto adds that there is value in the items on the right, but more in the items on the left. Twelve principles follow, covering frequent delivery, welcoming changing requirements, daily collaboration between business people and developers, sustainable pace, technical excellence and regular reflection. The full background is on the Wikipedia page for Agile software development.

What Agile gives a team

Because Agile is a way of thinking, its strengths are about attitude and direction rather than mechanics:

• Change is expected. Short planning cycles let a team reprioritise the backlog in weeks rather than carrying a fixed plan to the end.
• The end goal can start vague. Where the target is not clear at the start, the work itself exposes it, and the team adjusts as requirements emerge.
• Quality is built in. Small increments mean testing happens during the work, so defects surface early and cost less to fix.
• Customers stay involved. They see work often, comment on it and shape the product instead of receiving a surprise at the end.

What Agile does not give a team

• No prescribed practice. Agile alone does not say how to plan, estimate or hold meetings, so teams that adopt only the vocabulary often change very little.
• Less predictable dates. With priorities reshuffled and iterations added, a firm delivery date is harder to promise.
• Documentation can slip. Preferring working software over comprehensive documentation is sometimes read as permission to document nothing.
• It demands committed people. Agile relies on skilled, engaged team members and on stakeholders who actually take part.

What does the Scrum Guide actually prescribe?

The Scrum Guide, written by Ken Schwaber and Jeff Sutherland, defines Scrum as "a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems." The current edition is the November 2020 version, which you can read in full on the Scrum Guide page at Scrum.org. Its content is short, but every part is deliberate.

Theory and values

Scrum rests on empiricism and lean thinking, and on three pillars: transparency, inspection and adaptation. Five values support them: Commitment, Focus, Openness, Respect and Courage. This is the point where Scrum shares the most ground with Agile, since both prefer learning from what is observed to following a long upfront plan.

The Scrum Team: three accountabilities

Older descriptions often speak of three roles and a team of five to seven. The 2020 Guide is different. It describes one Scrum Team made up of a Scrum Master, a Product Owner and the Developers, with no sub-teams or hierarchy, and a size of "typically 10 or fewer people." It also uses the word accountabilities rather than roles:

• Developers create a usable Increment each Sprint, build the Sprint Backlog, hold themselves to a Definition of Done and adapt the plan every day toward the Sprint Goal. The word covers anyone who does the work, not only programmers.
• The Product Owner is one person, not a committee, accountable for maximising the value of the product and for managing the Product Backlog, including the Product Goal.
• The Scrum Master is accountable for establishing Scrum as defined in the Guide and for the team's effectiveness. The Guide calls Scrum Masters true leaders who serve the team and the organisation, which is why the post is not a project manager's under another name.

Five events inside one container

The Sprint is a fixed-length event of one month or less, and it contains the other four events: Sprint Planning (a maximum of eight hours for a one-month Sprint), the Daily Scrum (fifteen minutes), the Sprint Review (a maximum of four hours for a one-month Sprint) and the Sprint Retrospective. Older articles often say sprints last one to two weeks. Two weeks is common, but the Guide's actual limit is one month.

Three artifacts, each with a commitment

The Product Backlog carries the Product Goal, the Sprint Backlog carries the Sprint Goal, and the Increment carries the Definition of Done. Each commitment gives its artifact a stated target to be judged against, which keeps work visible and open to inspection.

How do Scrum and Agile compare side by side?

The table lines the two up on the questions people usually ask. Read each row as "what kind of thing is this?" rather than "which one is better?"

Question	Agile	Scrum
What kind of thing is it?	A mindset: four values and twelve principles	A framework: defined roles, events and artifacts
Where is it defined?	The Manifesto for Agile Software Development (2001)	The Scrum Guide (current edition November 2020)
Does it say who does what?	No	Yes: Developers, Product Owner, Scrum Master
Does it set a rhythm?	It asks for frequent delivery but sets no cycle	Sprints of one month or less, with five events
Is it only for software?	Born in software, now used far beyond it	Rooted in software, used for any complex work
Can you do it partly?	Yes, values can guide any practice	The Guide warns that dropping elements limits the benefits
How does it handle change?	Welcomes change at any stage	Changes go through the Product Owner and the Product Backlog
What proves you did it right?	Working software and satisfied customers	A usable Increment that meets the Definition of Done every Sprint

A fair way to put the table in a sentence: Agile is the direction and Scrum is one specific road. The Manifesto leaves a team free to choose its practices, whereas the Guide says that changing the core design of Scrum or leaving out elements "covers up problems and limits the benefits of Scrum."

Where does the "Scrum is a subset of Agile" idea help, and where does it mislead?

Most introductions say Scrum is a subset of Agile, and for ordinary purposes that is correct. Scrum's authors, Ken Schwaber and Jeff Sutherland, were among the seventeen who signed the Manifesto, and the Sprint, the self-managing team and the regular inspection of working software all express Agile values.

The phrase misleads in two ways. First, the Scrum Guide never mentions the Agile Manifesto. Scrum describes itself through empiricism and lean thinking and says it can be used for any complex problem, from products to research to marketing. Calling it merely a smaller version of Agile software practice undersells that scope. Second, "subset" suggests that doing Scrum automatically makes a team Agile. It does not. A team that runs all five events on schedule but never changes course based on what it learns has copied the shape of Scrum and missed its purpose, which is the same mistake as saying "we are Agile" because the stand-ups happen.

A cleaner image is a framework inside a philosophy. The philosophy states what matters. The framework removes some choices so a team can start working without inventing a process from scratch.

Pros and cons of Scrum as the framework you pick

• Clarity. Everyone knows who owns the backlog, who does the work and when the next inspection happens, which makes problems visible early.
• Team accountability. No manager assigns the work. The team decides what it can finish in a Sprint and manages itself.
• Easy to absorb change. Short Sprints and a backlog the Product Owner reorders every day make a changed priority cheap to accept.
• It costs experience. The Guide is short but the practice is hard. A team new to self-management often needs a skilled Scrum Master and patience.
• Scope creep. Because the backlog never closes, stakeholders can keep asking for more unless the Product Goal and the Product Owner's ordering hold the line.
• The wrong Scrum Master harms the team. A Scrum Master who directs people instead of coaching them undermines self-management, and the framework stops working.
• Vague items cause bad forecasts. Unclear Product Backlog items make Sprint Planning slow and Sprint outcomes unpredictable.

Which other methods sit under the Agile umbrella?

Scrum is the most widely adopted Agile framework, but it is far from the only one. Extreme Programming (XP) focuses on engineering practices such as test-driven development and pair programming. Kanban visualises work on a board and limits how much is in progress at once, with no fixed iterations. Lean software development, Feature-Driven Development and the Dynamic Systems Development Method each stress different ideas about flow, features or timeboxing. Many teams mix them, for example running Sprints while borrowing Kanban's work-in-progress limits and XP's testing habits.

The mix matters for this article's main point. If Scrum were the same as Agile, there would be nothing to combine. Teams combine because each method answers a different question. Scrum answers "how do we organise a team around fixed-length cycles of inspected progress?" XP answers "how do we write code we can change safely?" Kanban answers "how do we keep work flowing without overload?" Agile answers none of those and asks all of them to respect the same values.

Scaling frameworks add another layer, from Nexus and LeSS to SAFe, but they are not covered here. In every case the test is the same: do the practices help the team deliver working increments, learn from feedback and respond to change?

Can a team be Agile without Scrum, or run Scrum without being Agile?

Yes to both, and that is the strongest proof that they are separate ideas.

Agile without Scrum

A support team using Kanban, with a visible board, limited work in progress and a weekly review with its customers, can honour all four Manifesto values without a single Sprint. So can a small product team that releases daily and talks to users every week with only a light version of XP. No Scrum events, no Product Owner title, and still Agile in the sense the Manifesto means.

Scrum without Agile

A team can also pass every outward test of Scrum and stay far from the Manifesto. Typical signs are a Product Owner who is a proxy for a distant committee and cannot make decisions, a Sprint Backlog dictated from above, a Daily Scrum used as a progress report to the Scrum Master, and a Sprint Review where nothing is learned because the Increment is never in a usable state. Practitioners have a name for this pattern, "Scrum, but": we do Scrum, but we skip the Retrospective, but we keep the specification fixed, but we do not talk to customers. Each "but" removes an element the Guide treats as necessary.

Signs a team is doing it for real

• The Product Backlog changes every week because people are learning from users.
• The Sprint Goal is met by adjusting the scope, not by working late.
• The Retrospective produces at least one change the team actually tries in the next Sprint.
• Stakeholders attend the Sprint Review because the Increment is worth looking at.
• The Scrum Master spends more time coaching than scheduling.

What does the distinction mean for your career and for PSM I?

For a hiring manager the difference between Scrum and Agile is a quick test of depth. A candidate who can say "Agile is the values, Scrum is the framework, and here is a case where the two pulled in different directions" sounds like someone who has done the work. That kind of answer also marks the line between reading the Guide and understanding it, which is what a Scrum certification examines.

Scrum.org's entry-level credential is the Professional Scrum Master I (PSM I). Its assessment is built on the Scrum Guide, and the exam details below come from the exam sheet, with the vendor's own description on Scrum.org's PSM I page.

Detail	PSM I
Exam code	PSM I
Vendor	Scrum.org
Exam fee	USD $200
Duration	60 minutes
Number of questions	80
Passing score	85%

The topic of this article feeds directly into that exam in one place. PSM I questions assume you know that Scrum Team members are accountabilities in one team, that the Sprint is the container, and that the Product Owner is one person. A candidate who believes the older "three roles, five to seven people" description will lose marks on exactly the points where the 2020 wording differs. The PSM I syllabus page lists the areas the assessment covers, and a rehearsal with the PSM I practice exam is a fair way to find out whether the Guide's phrasing has stuck.

This is only a pointer. Preparing for the credential is a separate subject, and it is better handled with the vendor's materials than with a comparison article.

Why do "Scrum, but" teams lose the benefits?

When the Scrum Guide says to try Scrum "as is," it is making a testable claim: the parts depend on each other. Each event exists to inspect one thing, each artifact makes one thing visible, and each accountability prevents one failure. Remove one and a hole opens.

• Skip the Retrospective and the team stops improving, so the process hardens into habit.
• Skip the Sprint Review and the Product Owner loses feedback, so the backlog drifts from what customers need.
• Skip the Definition of Done and the Increment is not reliably usable, so progress cannot be trusted.
• Split the Product Owner role across a committee and ordering the backlog becomes negotiation, so the team gets mixed signals.
• Let the Scrum Master become a manager and the team stops managing itself.

The Agile response is not to defend the rules for their own sake. It is to ask what each rule protects, and to change a practice only when the team knows what it will lose and what it hopes to gain. That is the difference between adapting Scrum on purpose and quietly drifting away from it.

A short checklist for explaining the difference

1. Define Agile in one sentence: four values and twelve principles about how to approach software work.
2. Define Scrum in one sentence: a framework of one team, five events and three artifacts, built on empiricism.
3. Name the relationship: Scrum is one way to practise Agile, written by two of the Manifesto's authors.
4. Give a case of Agile without Scrum, such as a Kanban team.
5. Give a case of Scrum without Agile, such as a Daily Scrum run as a status report.

If you can do those five steps without notes, you understand the topic better than most job adverts do.

Frequently Asked Questions

Is Scrum part of Agile?

Yes, in the sense that Scrum is one framework for putting Agile values into practice, and two of its creators signed the 2001 Manifesto. But the Scrum Guide describes Scrum on its own terms, empiricism and lean thinking, and a team running Scrum is not automatically Agile in spirit.

What is the main difference between Scrum and Agile?

Agile is a mindset made of four values and twelve principles that does not prescribe any practice. Scrum is a defined framework with one Scrum Team, five events and three artifacts. Agile tells you what to value; Scrum tells you what to do each Sprint.

Can you do Agile without Scrum?

Yes. Kanban, Extreme Programming, Lean and plenty of home-grown approaches can follow the Agile Manifesto without Sprints or a Product Owner. A support team with a visible board, limited work in progress and regular customer feedback is Agile without using Scrum at all.

Is Scrum a methodology or a framework?

The Scrum Guide calls it a lightweight framework. It is purposefully incomplete and only defines the parts needed to apply Scrum theory, leaving techniques such as estimation or engineering practices to the team. A methodology would normally prescribe those details as well, which Scrum deliberately does not.

How long is a Sprint in Scrum?

The 2020 Scrum Guide sets Sprints as fixed-length events of one month or less. Many teams choose two weeks, but the Guide does not require it. Shorter Sprints give more learning cycles and limit risk, while a Sprint that runs too long can make the Sprint Goal invalid.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (76 votes)