What Is Scrum? A Clear Definition and How It Really Works

A teammate announces “we’re doing Scrum now,” or a job listing requires it, and the definitions you find online don’t quite explain what you’re being asked to do.

Scrum is a framework for managing complex, unpredictable work most often software development in which a small team plans a short cycle of work, builds something usable within it, and inspects the result before planning the next one. Jeff Sutherland and Ken Schwaber formalized it in 1995 and still co-maintain its official rulebook, the Scrum Guide, now in its 2020 edition. Sprints, standups, backlogs, and the Scrum Master role are the specific mechanisms built to make that idea repeatable.

Most explanations stop at that description. This one also covers how the framework holds up once real deadlines and office politics get involved, and what changed in 2025 when one of Scrum’s own creators published an update the field hasn’t fully absorbed.

The problem Scrum was built to solve

Scrum exists because detailed, upfront planning fails on work where nobody yet knows the full solution, which describes most software development. The approach it pushed back against, often called waterfall, plans requirements, design, build, and testing in full before anything ships. That works when the problem is well understood in advance and breaks when it isn’t, because by the time a nine-month specification reaches delivery, the market or the team’s understanding of the problem has usually moved.

The name comes from a 1986 Harvard Business Review paper, “The New New Product Development Game,” in which Hirotaka Takeuchi and Ikujiro Nonaka studied fast-moving product teams at companies like Honda and Canon and compared their overlapping, all-hands style to a rugby scrum. Jeff Sutherland, John Scumniotales, and Jeff McKenna built the first software version of it at Easel Corporation in 1993; Sutherland and Ken Schwaber formalized and presented it jointly at the OOPSLA conference in 1995.

The mechanism they landed on is empirical rather than predictive: a team builds a small piece, inspects what it learns from actually building and showing it, and adapts the plan before the next piece. The Scrum Guide calls these three moves transparency, inspection, and adaptation, and treats them as the pillars everything else in the framework supports.

The practical payoff of that cycle is speed of correction. A wrong assumption surfaces at the next Sprint Review, a few weeks in, instead of at launch, months in and expensive to undo.

Scrum vs. Agile vs. Kanban: how the three relate

Agile is a set of values and principles from the 2001 Agile Manifesto, not a method you can adopt directly, and it has no roles, meetings, or artifacts of its own. Scrum and Kanban are two different frameworks teams use to practice those values. Scrum actually predates the Manifesto: Sutherland and Schwaber were among its seventeen authors, generalizing partly from Scrum itself.

Scrum and Kanban solve the same underlying problem, delivering value in small increments instead of one big release, through different mechanics:

Teams that need forced rhythm and reflection get more out of Scrum. Teams whose priorities shift daily, like a support queue, get more out of Kanban’s continuous pull, or a hybrid some teams call Scrumban.

The three roles on a Scrum Team

A Scrum Team has exactly three kinds of accountability: Product Owner, Scrum Master, and Developers, with no project manager, no sub-teams, and no hierarchy among them. The whole team is capped at ten people for a reason: past that size, coordination overhead eats the gains Scrum is supposed to produce.

The Product Owner is one person, not a committee, accountable for maximizing the product’s value and for ordering the Product Backlog so the highest-value work is always next. “Developers” is the Scrum Guide’s term for whoever builds the product each Sprint: engineers, but also designers or writers, depending on what the product needs. They own the Definition of Done, the quality bar every piece of work must clear. The Scrum Master is the accountability people most often misread: not a project manager who assigns tasks, but someone responsible for the team’s ability to manage itself, remove its own obstacles, and run the Scrum events well. Nobody on a Scrum Team assigns work to anyone else; Developers pull items from the Sprint Backlog themselves.

The five events, and what each is actually for

Scrum organizes all work inside a Sprint, a fixed cycle of a month or less, and structures that cycle with four more events.

Shorter Sprints get proportionally shorter timeboxes: a two-week Sprint has a four-hour Sprint Planning, not an eight-hour one. The timeboxes are maximums, not targets, and a Daily Scrum that wraps in eight minutes isn’t a problem. What trips teams up is treating these as status meetings instead of the framework’s actual working mechanism. The Daily Scrum is Developers coordinating with each other, not reporting to a manager. A Sprint Review that turns into a slide presentation instead of a working demo has stopped doing its job.

The three artifacts, and the commitment behind each

Scrum’s three artifacts are the Product Backlog, the Sprint Backlog, and the Increment, and each carries a commitment: a stated goal that keeps the artifact from becoming just a list of tasks.

The Product Backlog is the single ordered list of everything that might improve the product; its commitment is the Product Goal, the target the team works toward across several Sprints, not just the current one. The Sprint Backlog, by contrast, is the Developers’ own plan for the current Sprint, and its commitment is the Sprint Goal: the one objective that keeps the Sprint coherent even as individual tasks shift. The Increment is the working product that results from the Sprint, tied to the Definition of Done, a checklist, specific to each team, of what “finished” actually means. Until a piece of work meets it, that work isn’t an Increment yet; it goes back on the Product Backlog, no matter how close it looked to complete.

The five values underneath the mechanics

Scrum names five values that are supposed to hold the framework together, and they’re the part most introductory training skips in favor of the roles and events:

• Commitment to the Sprint Goal and to teammates, not to a scope that can’t change once it’s discovered to be wrong.
• Focus on the Sprint’s goal and the backlog’s top items, not on everything the backlog could eventually include.
• Openness about the work and its obstacles, including saying a Sprint is off track before the Review forces the admission.
• Respect for teammates’ competence to manage their own work without being told how.
• Courage to raise a hard problem, challenge a decision, or say no to added scope mid-Sprint.

They matter because the roles and events are just structure. A team can run every ceremony correctly and still fail if nobody is honest in the Daily Scrum or nobody has the standing to push back on the Product Owner.

Who actually uses Scrum, and how closely they follow it

Independent surveys of Agile teams, the long-running State of Agile report chief among them, have consistently found Scrum or a Scrum-based hybrid to be the most common approach teams report using, ahead of Kanban, Extreme Programming, or any other named framework. The same surveys point to a trend that gets less attention: a majority of those teams now describe what they run as a hybrid or self-modified version, not the framework as the Scrum Guide defines it.

That gap isn’t automatically a failure. The Scrum Guide has never objected to teams adding practices; story points and velocity charts aren’t in it at all, and teams borrowed them from elsewhere because they were useful and kept them. The gap becomes a problem only when a team calls something “Scrum” while dropping the accountabilities and events that make it work, then blames the framework for what’s actually a home-grown process wearing its name.

Where Scrum breaks down in practice

A handful of Scrum failure patterns show up again and again, and none of them are exotic.

• No real Definition of Done. Teams let “done” mean “code complete” instead of “tested, integrated, and shippable,” and hidden work piles up until a release date arrives and forces all of it into view at once.
• A Product Backlog that isn’t actually ready. When items reach Sprint Planning with no clear acceptance criteria, no sizing, and unresolved dependencies, the team spends the Sprint discovering scope instead of building it.
• A Scrum Master who is a project manager with a new title. Assigning tasks and reporting status upward keeps the exact dysfunction the role was supposed to remove.
• Velocity treated as a performance metric. It exists to help a team forecast its own capacity. The moment a manager compares it across teams or sets a target for it, teams inflate estimates instead of building software, and the number stops meaning anything.

Most of these trace back to adopting Scrum’s vocabulary without its authority structure: a Product Owner who can’t actually reorder the backlog because a VP overrides it, or a team that can’t push back on mid-Sprint requests because the person asking outranks the Scrum Master. Scrum assumes a level of organizational discipline the framework itself has no power to enforce.

What changed in 2025: the Scrum Guide Expansion Pack

The document teams are still taught from is the 2020 Scrum Guide. But in June 2025, Jeff Sutherland published a supplementary “Scrum Guide Expansion Pack” with Ralph Jocham and John Coleman. It doesn’t replace the 2020 Guide, which both Sutherland’s and Schwaber’s organizations still treat as the official reference, and it hasn’t been folded into the certification material at Scrum.org, Schwaber’s organization, or the Scrum Alliance, the one Sutherland co-founded.

What it adds is mostly clarification rather than new rules: an explicit “Discovery” activity for validating what stakeholders need before building it, more attention to product strategy, and a broader view of leadership that isn’t concentrated in the Scrum Master alone. Reaction from the practitioner community has been mixed, with some welcoming the update and others questioning whether a framework built on being lightweight needs a supplementary document at all. Treat it as a sign that Scrum is still being actively revised by the people who created it, not as a new standard to adopt.

Is Scrum right for your team?

Scrum fits work where the requirements or the solution are genuinely unclear at the start, and where showing something real to stakeholders every few weeks would change what gets built next. That describes most product and software development, and a growing list of non-software work with the same shape: marketing campaigns, curriculum design, and hardware teams that can prototype in short cycles. It fits poorly where work arrives unpredictably and needs handling the day it shows up, like a support queue, where Kanban’s continuous flow serves better than Scrum’s fixed cycles.

The two credentials most people mean by “Scrum certified” are the Professional Scrum Master from Scrum.org and the Certified ScrumMaster from the Scrum Alliance. Neither is required to start: a team can run its first Sprint after reading the Scrum Guide directly, which is thirteen pages, free, and the actual source everything on this page describes.

Everything above describes Scrum for a single team. Running it across many teams at once is a different problem with its own frameworks – SAFe, LeSS, and Scrum@Scale each answer it differently and none of them are covered here.

The real test isn’t whether a team can name the five events. It’s whether, after the first two or three Sprints, the Product Owner has genuine authority over the backlog, the team gets uninterrupted time to work it, and the Retrospective produces a change that actually sticks. A team missing those three things isn’t doing Scrum yet, whatever it calls the daily standup.