Ask ten developers what "scrum agile" means and you will get ten answers that overlap but never quite line up. The phrase itself is a small mistake people made on purpose. Agile is the philosophy. Scrum is a framework. You don't really do "scrum agile" — you do Scrum, and Scrum is how a team puts Agile Manifesto values into a working rhythm.
Why does the distinction matter? Because teams that confuse the two end up cargo-culting the ceremonies (the standups, the sprint reviews) while ignoring the principles that make those ceremonies useful. They run sprints without inspecting their work. They hold retrospectives that change nothing. They get the choreography right and miss the music.
This guide walks through both layers. We will cover what Agile actually is — four values, twelve principles, written in 2001 by seventeen people in a Utah ski lodge. Then we will cover Scrum in detail: three roles, five events, three artifacts, and a few things the 2020 Scrum Guide changed that older teams still get wrong. You will see how Scrum compares to other agile framework options like Kanban and XP, what scaling looks like with SAFe and LeSS, which certifications actually move salaries, and how to spot "ScrumBut" before it eats your team.
Start with what Agile is not. Agile isn't a methodology, isn't a process, isn't a job title. Agile is a mindset — a set of preferences written down in February 2001 and called the Agile Manifesto. Seventeen software developers signed it. Most of them already had their own lightweight methods (Scrum, XP, Crystal, DSDM, FDD), and they were tired of watching big-document, big-plan projects fail in slow motion.
The Manifesto has four values, each phrased as a preference, not an absolute. 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 trailing sentence is the part teams forget: "while there is value in the items on the right, we value the items on the left more." Nobody said tools and documentation are bad. They are second.
Behind the four values sit twelve principles. Deliver working software frequently. Welcome changing requirements, even late. Business and developers work together daily. Build projects around motivated individuals. The principles are concrete enough to argue about and abstract enough to apply anywhere — software, hardware, marketing, education, anywhere you build something complex over time.
What does this look like in what is agile practice? A team that genuinely lives the Manifesto talks to its customers, not about them. It ships small, frequent increments instead of one big launch. It treats its plan as a hypothesis, not a promise — and when the world disagrees with the hypothesis, the plan changes.
The work is done by people who can actually decide things, not by people waiting for permission. None of that is unique to software. Hospitals run Agile programs. School districts run Agile programs. Marketing departments run Agile programs. The Manifesto was written by software people because that's the industry that was on fire in 2001 — but the values weren't.
One sentence summary: Agile is a set of values; Scrum is one of several frameworks that puts those values into a weekly rhythm. Kanban, Extreme Programming (XP), Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Disciplined Agile, and Crystal are also agile frameworks. You can be Agile without using Scrum, but it is harder to use Scrum well without an Agile mindset. The 2020 Scrum Guide makes this explicit: Scrum is described as a "lightweight framework" — not a complete methodology, not a recipe.
Scrum predates the Agile Manifesto by about six years. Jeff Sutherland built the first version at Easel Corporation in 1993; he and Ken Schwaber presented the formal pattern at the OOPSLA conference in 1995. They borrowed the name from a 1986 Harvard Business Review paper by Takeuchi and Nonaka titled The New New Product Development Game, which compared high-performing product teams to rugby players in a scrum — a single unit passing the ball back and forth, moving downfield together.
For years Scrum lived as a folk practice. Sutherland and Schwaber didn't write the official Scrum Guide until 2010. That document has been refreshed several times. The 2017 update added the Definition of Done and clarified the Product Owner role.
The 2020 update is the one most current teams reference: it dropped the requirement to commit to a fixed scope at sprint planning (replaced with a Sprint Goal plus a forecast), renamed the "Development Team" to just "Developers" inside a unified Scrum Team, and added the Product Goal as a longer-term anchor above the Sprint Goal. The 2020 Guide is also notably shorter and less prescriptive than older versions — Schwaber and Sutherland trimmed it to about 13 pages because over-prescription was producing checkbox Scrum.
Decides what the team builds and in what order. One person, not a committee. Owns the Product Backlog, writes or refines user stories, sets the Product Goal, and is accountable for maximizing the value of the work the developers do. Talks to stakeholders, customers, and users so the team doesn't have to. The Product Owner can delegate the writing but not the decision.
Servant-leader for the team and the organization around it. Not a project manager, not a team lead, and not the developer's boss. The Scrum Master facilitates events, removes blockers, coaches the Product Owner on backlog techniques, helps the organization adopt Scrum, and protects the team from mid-sprint changes. A common test: if removing the Scrum Master would not change the team's behavior, the Scrum Master is not doing the job.
Three to nine people who actually build the increment. Cross-functional — the team as a whole has every skill needed to take a backlog item from "ready" to "done." Self-managing: they decide how to break work down and how to complete the Sprint Goal. The 2020 Scrum Guide deliberately uses "Developers" as a generic term, not just "programmers." Testers, designers, data engineers, and writers all qualify if they help build the increment.
Scrum runs on a heartbeat called the Sprint, and inside each Sprint there are four other events. People who learn Scrum often memorize the five events without grasping what each one is actually for. The events exist to create transparency, inspection, and adaptation — the three empirical pillars Scrum is built on. Every event is a chance to look at something and decide whether to keep going or change course.
Read each event below as a question the team is trying to answer. Sprint Planning answers "what can we do, and how?" The Daily Scrum answers "are we still on track for the Sprint Goal, and what should we do in the next 24 hours?" The Sprint Review answers "what did we just build, and what should we build next?" The Sprint Retrospective answers "how are we working together, and what can we change?" The Sprint itself answers "can we deliver a usable increment in this much time?"
The container for all the other events. A Sprint is a fixed-length iteration, usually two weeks but anywhere from one to four. The length stays the same so the team builds a predictable rhythm. Scope can flex; deadline does not. A new Sprint starts immediately after the previous one ends — there is no "week off" between Sprints. The Scrum Team can cancel a Sprint only if its Sprint Goal becomes obsolete, and only the Product Owner has authority to do that.
Max 8 hours for a 4-week Sprint; proportionally less for shorter Sprints. The whole Scrum Team participates. Output is a Sprint Goal (a single short sentence that captures why the Sprint matters) plus a forecast of which backlog items the developers think they can complete. Note: forecast, not commitment. Older Scrum versions used the word "commit" — the 2020 Guide replaced it with "forecast" precisely because rigid commitment was producing dishonest planning.
15 minutes max, every day of the Sprint, same time, same place. For the developers; the Product Owner and Scrum Master may attend if they are also doing development work. The point isn't a status report — the point is for the developers to inspect progress toward the Sprint Goal and adjust the plan for the next 24 hours. The classic three questions (what did you do, what will you do, what's blocking you) are optional; the only requirement is that the meeting moves the team closer to the Sprint Goal.
Max 4 hours for a 4-week Sprint. The Scrum Team plus stakeholders inspect the increment and discuss what's next. This is a working session, not a PowerPoint presentation. The developers show running software; the Product Owner explains what got done and what didn't; everyone talks about the market, user feedback, and the next Sprint's direction. The Product Backlog is adjusted right there if needed.
Max 3 hours for a 4-week Sprint. Closes the Sprint. The whole Scrum Team looks at people, interactions, processes, and tools — and identifies one or two changes to try in the next Sprint. Skipping retrospectives is the most common form of "ScrumBut" ("we do Scrum, but we don't do retros"), and it kills the inspect-and-adapt loop that makes Scrum work. A team that doesn't change anything between Sprints isn't really doing Scrum.
Three artifacts hold the team's work. The Product Backlog is the ordered list of everything that might ever be built — features, bugs, technical work, research. The Product Owner owns it; the developers help refine it. The Sprint Backlog is the subset the developers have chosen for the current Sprint, plus a plan for delivering them. The Increment is what gets built — a working slice of the product that meets the Definition of Done. Multiple increments can ship during a Sprint, and they don't have to wait for the Sprint Review.
Two concepts are not artifacts but show up everywhere. The Definition of Done is a shared agreement about what "finished" means — code reviewed, tests passing, deployed to staging, documentation updated, whatever the team decides. Without a Definition of Done, "done" becomes a moving target and the increment is never really shippable. The Definition of Ready (less universal, not in the Scrum Guide) describes when a backlog item is clear enough to pull into a Sprint. Some teams use it strictly; others find it creates artificial gatekeeping.
Scrum also names five values: commitment, courage, focus, openness, and respect. They sound like a corporate poster, but they are the cultural scaffolding the framework needs. Without courage, retrospectives become polite. Without openness, the Daily Scrum becomes a performance for the boss. Without focus, the Sprint Goal becomes a wishlist. The framework can be copied; the values cannot.
Scrum is the most-used agile framework, but it isn't the only one and it isn't always the right one. Kanban is the obvious alternative — same Agile values, very different rhythm. Kanban runs continuous flow instead of fixed-length Sprints, limits work in progress to expose bottlenecks, and has no prescribed roles or ceremonies. Teams doing operational or support work (where the next ticket can't be planned a week in advance) usually pick Kanban over Scrum. Some teams blend the two and call it Scrumban.
Extreme Programming, written down by Kent Beck in the late 1990s, focuses on engineering practices the way Scrum focuses on process: pair programming, test-driven development, continuous integration, refactoring, simple design. Many high-performing Scrum teams have quietly imported XP practices to handle the "how do we actually build this?" gap Scrum leaves on purpose. Crystal (Alistair Cockburn) is a family of methods sized to team scale. Disciplined Agile (originally IBM's, now PMI's) is a hybrid toolkit designed for enterprise contexts where one framework doesn't fit.
When you need more than one team working on the same product, scaling frameworks appear. The big four: SAFe (Scaled Agile Framework) is the most prescriptive, popular in regulated and large enterprises. LeSS (Large-Scale Scrum) is the strictest about staying true to vanilla Scrum at scale. Nexus, written by Schwaber himself, layers a small integration team over multiple Scrum Teams. The Spotify Model — squads, tribes, chapters, guilds — isn't actually a framework, it's a snapshot of one company's culture in 2012 that got copied into a thousand decks. Spotify themselves have moved on.
Scrum doesn't prescribe metrics, but most teams settle on a small set. Velocity is the number of story points the developers complete per Sprint. It is a planning tool, not a performance score — comparing velocities across teams is a classic anti-pattern. The Sprint Burndown shows remaining work across the Sprint and is supposed to slope downward; a flat or rising burndown signals that the Sprint Goal is at risk. Cycle time (start of work to done) and lead time (request to delivery) come from Kanban but have quietly crept into Scrum teams that want flow data alongside their velocity.
The metric that matters most isn't on any dashboard. It is the rate at which the team can change direction. Scrum exists to surface what's working and what isn't, every couple of weeks, so the next bet is better than the last one. A team with great burndown charts that ships the wrong product is failing at Scrum. A team that quietly cancels a Sprint because the market moved is succeeding.
One more measurement worth tracking: Sprint Goal achievement rate. Did the team hit the goal it set at Sprint Planning, or did it finish a bunch of stories that didn't add up to the goal? Goal achievement is a better health signal than velocity because it rewards focus over throughput. A team that finishes 40 points worth of unrelated work and misses the goal has a process problem. A team that finishes 25 points and nails the goal is doing Scrum the way it was designed.
Certification matters more for Scrum than for almost any other agile framework, partly because two organizations compete for the same market. Scrum.org (founded by Ken Schwaber) issues the Professional Scrum Master (PSM I, II, III) and Professional Scrum Product Owner (PSPO I, II, III) tracks. The exams are open-book online and harder than most candidates expect — pass rates for PSM I sit around 80 percent, and PSM II drops sharply. There is no mandatory class; you can sit the exam after self-study.
Scrum Alliance (Jeff Sutherland's side) issues the Certified ScrumMaster (CSM), Certified Scrum Product Owner (CSPO), Advanced Certified ScrumMaster (A-CSM), and Certified Scrum Professional (CSP-SM). CSM requires a two-day training class before the exam — a real cost gate, but the class is the actual value. Both PSM I and CSM are commonly listed in agile certification job postings, and most hiring managers treat them as interchangeable.
Beyond the basics: PMI's Agile Certified Practitioner (PMI-ACP) is broader than Scrum alone and covers Kanban, XP, Lean, and others. The Scaled Agile Framework has its own ladder (SAFe Practitioner, SPC, POPM), valuable when the target employer is a SAFe shop. Disciplined Agile Value Stream Consultant (DAVSC) is the heaviest credential PMI offers for agile leaders. Median Scrum Master salaries in the U.S. run roughly $95K to $120K, with $140K+ common in major tech metros and at senior levels.
Which certification actually moves a salary? Honest answer: the first one moves the needle most. Going from no Scrum credential to PSM I or CSM is what gets you past resume filters. The jump from PSM I to PSM II is meaningful for senior roles but matters less to junior hiring.
A second certification in a different track (PSPO if you have PSM, or PMI-ACP if you have CSM) signals breadth. Stacking three Scrum Master certifications rarely pays for itself. Pair a Scrum credential with real delivery experience and a story about a hard retrospective you ran — that combination beats any single certification on its own.
Three persistent misconceptions are worth flagging. First: "the Scrum Master is the project manager." No. Project managers track scope, schedule, and budget; Scrum Masters facilitate a process and remove impediments. The Product Owner makes scope decisions, the developers make schedule decisions, and the organization handles budget.
If your Scrum Master is reporting on red/yellow/green status to executives, somebody has reinvented the wrong role. Second: "if we do Scrum we don't need design or architecture." Also no. Scrum is silent on engineering practices because it expects the team to bring them. Teams that abandon up-front thinking in the name of Scrum produce technical debt at industrial scale.
Third: "Agile means no documentation." The Manifesto says working software over comprehensive documentation — over, not instead of. Teams still write architecture decision records, API specs, runbooks, and onboarding guides. They just don't write 200-page requirements documents before any code gets shipped. The test for whether documentation is "agile" is simple: is it useful, kept current, and read by the people who need it? Or does it exist only because a process says it must?
A fourth misconception worth naming: "velocity measures team productivity." Velocity is a planning aid the team uses to forecast the next Sprint. It is not a performance score, it can't be compared across teams (one team's 8-point story is another team's 3), and managers who treat it as a productivity number reliably get inflated estimates within two Sprints. The 2020 Scrum Guide doesn't even mention velocity. It's a useful tool that turns toxic the moment it leaves the team room.
If you take one idea from this guide, take this one: scrum and agile are layered, not interchangeable. Agile is the why — a set of values about software, customers, and change. Scrum is one of several hows — a framework for putting those values into a working week. Teams that learn the why first and the how second outperform teams that drill the ceremonies and skip the principles. The Scrum Guide is 13 pages. The Agile Manifesto is one. Both fit on a single screen. Read them, in that order, before you adopt any of it.
No. Agile is a mindset defined by the 2001 Agile Manifesto — four values and twelve principles. Scrum is a specific framework that implements those values. You can be Agile without using Scrum (Kanban, XP, Crystal, SAFe, and LeSS are other agile frameworks), but Scrum on its own is just a process — the Agile values are what make it work.
Product Owner (decides what to build and in what order), Scrum Master (facilitates the process and removes blockers; not a project manager), and Developers (three to nine cross-functional people who build the increment). Together they form a single Scrum Team — the 2020 Scrum Guide deliberately stopped separating "developers" from the rest of the team.
The Sprint (a fixed-length iteration, typically 2 weeks) is the container. Inside it are Sprint Planning (set the Sprint Goal and forecast), the Daily Scrum (15-minute developer sync), the Sprint Review (inspect the increment with stakeholders), and the Sprint Retrospective (inspect the team itself and pick one or two improvements for next Sprint).
The Product Backlog (ordered list of everything that might be built), the Sprint Backlog (what the developers chose for the current Sprint, plus a plan), and the Increment (the working slice of product produced this Sprint, meeting the Definition of Done). The Definition of Done is a shared agreement that supports the Increment but is not itself an artifact.
One to four weeks; two weeks is the most common. The length stays fixed so the team builds a rhythm. Shorter Sprints give faster feedback but more ceremony overhead. Longer Sprints reduce overhead but delay learning. Pick based on how often the market or your users actually change.
No. A project manager owns scope, schedule, and budget. A Scrum Master is a servant-leader who facilitates Scrum events, removes impediments, coaches the Product Owner on backlog techniques, and helps the organization adopt Scrum. Scope decisions belong to the Product Owner; how-to-build decisions belong to the developers. If your Scrum Master is tracking red/yellow/green status, someone has reinvented the wrong role.
For Scrum Master roles, either PSM I (Scrum.org, no required class, online open-book exam) or CSM (Scrum Alliance, requires a two-day class). Most hiring managers accept either. PSM I is cheaper but harder to self-study; CSM is more expensive but the class is real value. For Product Owner roles, PSPO I or CSPO. Add PMI-ACP if you want a broader Agile credential beyond Scrum.
ScrumBut is Ken Schwaber's term for partial adoption: "we do Scrum, but we skip retrospectives" or "we do Scrum, but we have no Product Owner." Each "but" removes one of the inspect-and-adapt loops Scrum depends on. The framework still looks like Scrum on the surface, but it has stopped producing the empirical feedback that makes it useful. The fix is rarely more rigid Scrum — it is figuring out which Agile principle the workaround is dodging.