Scrum
Scrum is a lightweight agile framework for developing complex products, in which a small team works in fixed-length cycles called sprints to deliver a usable increment, then inspects and adapts. It is the most widely adopted way of “doing agile.”
Scrum is deliberately minimal: it defines a handful of roles, meetings, and artifacts and then stops, leaving the team to fill in how they design, code, and test. That’s why it’s a framework, not a methodology. It’s a skeleton you flesh out, not a complete recipe.
Also known as
Scrum framework · (loosely and technically incorrectly) “the Scrum methodology” The name comes from rugby, where the team packs together to restart play, a metaphor from a 1986 Harvard Business Review article by Takeuchi and Nonaka.
Don't confuse with
The empirical foundation
Scrum is built on empiricism: knowledge comes from experience and decisions are based on what’s observed. This rests on three pillars:
- Transparency: the work and progress are visible to everyone.
- Inspection: artifacts and progress are checked frequently.
- Adaptation: when something’s off, adjust quickly.
Its five values give the culture that makes this work: commitment, focus, openness, respect, courage.
The Scrum Team
One small team (the 2020 Scrum Guide recommends 10 people or fewer), with no sub-teams and no hierarchy. It has three accountabilities (the current official word; older material says “roles”):
| Accountability | Owns | Also known as / watch out |
|---|---|---|
| Product Owner (PO) | What gets built and in what order; maximizes product value; owns the Product backlog. | Often confused with Product Manager, related but not identical; at some companies one person does both. |
| Scrum Master | The team’s effectiveness; coaches Scrum, removes impediments, protects focus. A servant-leader, not a boss. | Frequently mislabeled “project manager,” “delivery lead,” “iteration manager,” or “agile coach.” |
| Developers | How the work gets done; they build the increment. Includes everyone doing the work: engineers, designers, testers. | Called the “Development Team” before the 2020 guide. |
The team is not a hierarchy
The Scrum Master does not manage the Developers, and the Product Owner is not their boss. The three accountabilities are about ownership of different concerns, not rank.
The five events
All events happen inside the Sprint, which is itself the container event.
| Event | Purpose | Timing | Also known as |
|---|---|---|---|
| The Sprint | The fixed time-box (1 month or less) that holds all other events; produces one increment. | Continuous, back-to-back | ”iteration,” “cycle” |
| Sprint planning | Decide the Sprint Goal and select backlog items to build. | Start of sprint | ”planning,” “the planning meeting” |
| Daily Scrum | 15-minute team sync to inspect progress toward the Sprint Goal and re-plan the day. | Every day | ”standup,” “daily standup,” “morning sync,” “roll-call” |
| Sprint review | Show the finished increment to stakeholders and get feedback; adapt the backlog. | End of sprint | ”demo,” “sprint demo,” “show and tell” |
| Sprint retrospective | The team improves itself: its process, tools, and collaboration. | After the review | ”retro” |
The two end-of-sprint meetings everyone mixes up
Sprint review is about the product (did we build the right thing? Stakeholders attend). Sprint retrospective is about the team’s process (how do we work better? Team only). Also: a retrospective is not a post-mortem. Retros are regular and forward-looking; a post-mortem is a one-off analysis after an incident or a project ends.
Myth: the "three questions"
Older Scrum described the Daily Scrum as everyone answering “what did I do yesterday / today / any blockers?” The 2020 Scrum Guide dropped that as a requirement. The daily is whatever helps the team hit the Sprint Goal. Many teams still use the three questions out of habit.
The three artifacts (and their commitments)
Each artifact has a “commitment”, a target that gives it focus (added in the 2020 guide):
| Artifact | What it is | Commitment |
|---|---|---|
| Product backlog | The single ordered list of everything that might be built. | Product Goal: the long-term objective. |
| Sprint backlog | The items chosen for this sprint, plus the plan to build them. | Sprint Goal: the one objective of this sprint. |
| Increment | The sum of completed work; a usable, potentially shippable step toward the Product Goal. | Definition of Done: the shared checklist that makes work “done.” |
Definition of Done vs Acceptance Criteria
Definition of Done (DoD) is team-wide, the same quality bar for every item (tests pass, code reviewed, deployed to staging…). Acceptance criteria are per-story, the specific conditions that one User story must satisfy. An item can meet its acceptance criteria but still not be “done” if it fails the DoD.
A sprint, start to finish
One two-week sprint
- Sprint planning (Mon, wk 1): team picks a Sprint Goal and pulls items from the Product backlog into the sprint backlog.
- Build (wk 1–2): Developers design, code, and test the increment. Each morning: a 15-min Daily Scrum.
- Sprint review (Fri, wk 2): demo the working increment to stakeholders; gather feedback.
- Retrospective (Fri, wk 2): team agrees on one or two process improvements.
- Next sprint starts Monday. Repeat.
Scaling Scrum
For many teams on one product, organizations use scaling frameworks: Nexus, LeSS (Large-Scale Scrum), SAFe (Scaled Agile Framework), or Scrum@Scale. Scrumban blends Scrum’s cadence with Kanban’s flow.
See also
- Sprint: the time-box at Scrum’s core
- Agile software development · Agile Manifesto
- Kanban: the flow-based alternative
- Software development process: where Scrum sits among the approaches
References
- K. Schwaber & J. Sutherland, The Scrum Guide (2020). https://scrumguides.org/scrum-guide.html
- H. Takeuchi & I. Nonaka, The New New Product Development Game, Harvard Business Review 64 (January 1986), pp. 137–146. https://hbr.org/1986/01/the-new-new-product-development-game