“Agile” and “scrum” get used interchangeably in job posts, vendor demos, and standups. They’re not the same thing, and the confusion has practical consequences: teams adopt scrum thinking they’ve adopted agile, then conclude agile “doesn’t work” when scrum’s specific ceremonies don’t fit them. This post is the honest read on what each one actually is, where the boundary sits, and how to pick.
The one-line difference
Agile is a set of values. Scrum is one specific framework that tries to embody those values.
Agile says what good software development looks like (responding to change, working software, customer collaboration, individuals over process). Scrum says how one specific team-shape can deliver on that — with roles, ceremonies, artefacts, and a fixed cadence.
You can be agile without being scrum. You can do scrum and not be agile. Plenty of teams are both. Some are neither and don’t know it.
What agile actually says
The Agile Manifesto, written in 2001, has four value statements and twelve principles. The four values are the famous part:
- 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 key word is over — not “instead of.” The right side has value; the left side has more value. This nuance gets lost when teams declare a Word doc “not agile” or refuse to write a roadmap because “we’re agile.”
The twelve principles are more concrete: deliver working software frequently, welcome changing requirements even late, sustainable pace, technical excellence, simplicity, self-organising teams, regular reflection.
That’s it. No mention of standups, sprints, story points, retrospectives, scrum masters, or planning poker. Those all came later.
What scrum actually is
Scrum is a framework defined by the Scrum Guide (most recent version: 2020). It’s prescriptive about a small number of things and silent about most others.
The roles (three):
- Product Owner — owns the backlog and what gets built
- Scrum Master — owns the process working
- Developers — own the work
The events (five):
- Sprint — fixed-length iteration (1–4 weeks), typically 2
- Sprint planning — pick the work for this sprint
- Daily scrum — 15-minute team sync (often called standup)
- Sprint review — demo to stakeholders at the end
- Sprint retrospective — team reflects on the process
The artefacts (three):
- Product backlog — full list of potential work
- Sprint backlog — work committed to this sprint
- Increment — the working software produced
That’s the entirety of scrum-the-framework. Story points, planning poker, velocity, burndown charts, the whole “scrum-but” debate — none of these are in scrum. They’re widely-used add-ons.
Why the confusion exists
Three reasons the words got mashed together:
1. Scrum is by far the most adopted “agile” framework. State of Agile reports consistently put scrum or scrum-derivatives at 60–80% of agile teams. If most agile teams are scrum teams, “agile” and “scrum” become near-synonymous in casual conversation.
2. Scrum certifications dominate the training market. Certified ScrumMaster (CSM) and Professional Scrum Master (PSM) courses are the default path for managers learning agile. The course teaches scrum, the manager goes back and runs scrum, the team thinks it’s “doing agile.”
3. Vendor marketing collapses the distinction. Tool vendors sell “agile project management software” that’s really scrum tooling — sprints, story points, burndown. The label sticks.
The result: teams running standups, doing two-week sprints, and tracking story points believe they’re “agile.” They’re doing scrum. Whether they’re agile is a separate question — and the answer is often no.
How a team can do scrum and not be agile
This is where the distinction has real consequences.
A team that runs every scrum ceremony but:
- Refuses to change scope mid-sprint even when the customer’s needs shifted (violates “responding to change”)
- Has the Product Owner dictate every ticket without team input (violates “self-organising teams”)
- Tracks velocity as a productivity metric and pressures the team to push it up sprint over sprint (violates “sustainable pace”)
- Spends 4 hours per sprint in ceremonies for a 2-week sprint with 5 people (violates “individuals and interactions over processes”)
…is doing scrum. It’s not agile.
This is the famous “scrum-but” or “zombie scrum” pattern. The shape is there; the spirit isn’t.
How a team can be agile without scrum
Equally common, and often deliberately chosen:
- Kanban teams — continuous flow, no sprints, WIP limits, pull-based. Used heavily in support, ops, and platform teams. Often more agile than scrum teams because the team keeps replanning.
- Shape Up teams — 6-week cycles, no daily standups, autonomous teams, hill charts instead of burndown. Basecamp’s approach. Highly agile in spirit.
- XP (Extreme Programming) — pair programming, TDD, continuous integration, on-site customer. Older than scrum, more focused on engineering practice. Many “agile” engineering practices come from XP, not scrum.
- Pragmatic / no-name agile — small teams running 1-week iterations with a kanban board, a weekly demo, and a Friday retro. No scrum master, no story points, no planning poker. Highly agile.
Plenty of fast-moving startups operate this way. They’d fail a scrum certification audit. They ship constantly and respond to customer feedback in days, not sprints.
So which should we use?
The answer depends on three things.
1. How much existing structure does the team have? A team coming from chaos benefits from scrum’s prescriptive structure — it gives a starting point with five known events and three known roles. A team that already has good engineering rhythm finds scrum’s structure heavy.
2. How predictable is the work? Scrum assumes you can plan two weeks of work in a single planning meeting. If your work is reactive (support, ops, urgent customer escalations), kanban fits better. If it’s discrete and well-understood (feature delivery), scrum sprints work.
3. How big is the team? Scrum was designed for 5–9 people. At 3 people, the ceremony overhead dominates. At 20+, scrum needs scaling frameworks (SAFe, LeSS, Nexus) which most teams find heavy.
The honest recommendation
If you’re starting from nothing and want a framework: scrum, with these adjustments.
- Keep the four ceremonies (planning, daily scrum, review, retro).
- Drop the scrum master role unless you have a dedicated coach. The team can run its own process.
- Use story points or hours, whichever your team agrees on. Don’t be religious about either.
- Track velocity for forecasting, never as a productivity metric.
- After 8–10 sprints, look at what’s working and what isn’t. Drop ceremonies that don’t earn their time.
After 6 months, you’ll have a custom variant that works for your team. That’s the point. The Agile Manifesto values self-organising teams responding to change — including changes to their own process.
What this means for tool choice
If you’ve decided you want scrum, your tool should make sprints, retrospectives, and velocity tracking trivial — not a 30-step setup wizard. Most “agile project management” tools are over-built for scrum specifically and under-supportive of the rest of agile (kanban-only, hybrid, async retros).
SprintFlint is built around the scrum sprint cycle: fixed iterations, automatic velocity, native retros, story points, burndown. It assumes you’ve decided to do scrum-shaped agile and want the rituals to take five minutes, not a Tuesday.
If you’re not doing sprints — kanban, Shape Up, continuous flow — pick a tool optimised for your shape. Scrum tools fit awkwardly on kanban teams.
TL;DR
- Agile is a values document from 2001. Four values, twelve principles. No ceremonies prescribed.
- Scrum is one specific framework: three roles, five events, three artefacts. It’s the most-adopted implementation of agile.
- You can do scrum without being agile (zombie scrum). You can be agile without doing scrum (kanban, XP, pragmatic).
- Pick scrum if you want structure and your work is plannable in 2-week chunks. Pick something lighter if not.
- Whatever you pick, after a few months, customise it. That’s the most agile thing you can do.