Scrum Guide 2020 (Schwaber & Sutherland) — the current authoritative version.*
What Scrum Is
A lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Not a process or methodology — a container for other techniques. Appropriate when requirements and/or technology are uncertain.
Three pillars: Transparency · Inspection · Adaptation Five values: Commitment · Courage · Focus · Openness · Respect
The Scrum Team
The 2020 Guide eliminated the "team within a team" structure. There is one Scrum Team — no sub-teams, no hierarchies. Typically 10 or fewer people, cross-functional, self-managing, focused on one Product Goal at a time.
| Accountability | Responsibility |
|---|---|
| Product Owner | Single person accountable for maximizing the product's value. Owns the Product Backlog and decides what gets built. Final authority on requirements and release. |
| Developers | Anyone in the Scrum Team committed to building any aspect of a usable Increment each Sprint. Self-managing, cross-functional. No titles, no sub-teams. (Replaces the old term "Development Team".) |
| Scrum Master | True leader who serves the Scrum Team and the wider organization. Accountable for the team's effectiveness. Coaches, removes impediments, ensures Scrum is understood and practiced. |
Scrum Master serves:
- The Product Owner — backlog management techniques, facilitating effective Product Goal definition
- The Developers — coaching in self-management and cross-functionality, removing impediments
- The Organization — leading and coaching Scrum adoption, raising effectiveness
Events
All events are time-boxed. Sprint duration is fixed once started. The Sprint contains all the other events.
| Event | Who | When | Time-box | Purpose |
|---|---|---|---|---|
| Sprint | Whole Scrum Team | Continuous, back-to-back | ≤ 1 month | Container for all work; produces a usable Increment |
| Sprint Planning | Whole Scrum Team | Start of Sprint | 8h (1-month Sprint) | Define Sprint Goal, select backlog items, plan how to deliver |
| Daily Scrum | Developers (PO/SM optional) | Every day, same time/place | 15 min | Inspect progress toward Sprint Goal, adapt the Sprint Backlog |
| Sprint Review | Whole Scrum Team, stakeholders | Toward end of Sprint | 4h (1-month Sprint) | Inspect Increment with stakeholders, adapt Product Backlog |
| Sprint Retrospective | Whole Scrum Team | After Review, before next Planning | 3h (1-month Sprint) | Inspect the team's process — people, interactions, tools, DoD — and improve |
Sprint Planning (Three Topics — new in 2020)
- Why is this Sprint valuable? → produces the Sprint Goal
- What can be done this Sprint? → Developers select Product Backlog items
- How will the chosen work get done? → plan the Sprint Backlog
Daily Scrum (No More Three Questions)
The 2020 Guide dropped the prescribed three questions ("What did I do / will I do / blockers"). Developers choose whatever structure helps them progress toward the Sprint Goal. The focus is the Sprint Goal, not status reporting.
Sprint Cancellation
Only the Product Owner can cancel a Sprint (e.g., if the Sprint Goal becomes obsolete). Rare and disruptive. Completed work is reviewed; incomplete items return to the Product Backlog.
Artifacts & Commitments
Each artifact in the 2020 Guide has a commitment that reinforces transparency and focus.
| Artifact | Commitment | Description |
|---|---|---|
| Product Backlog | Product Goal | Ordered, living list of what's needed to improve the product. The Product Goal is the long-term objective the team plans against. |
| Sprint Backlog | Sprint Goal | Selected items + plan + the Sprint Goal. Only Developers can change it during the Sprint. The Sprint Goal makes the Sprint coherent. |
| Increment | Definition of Done | A concrete step toward the Product Goal. Each Increment must meet the DoD to be usable. Multiple Increments can be produced within a Sprint. |
Definition of Done
Formal description of the state of the Increment when it meets the quality measures required for the product. Created and owned by the Scrum Team (or set organization-wide). If the organization has a standard, the team follows it as a minimum. Work that doesn't meet DoD cannot be released and returns to the Product Backlog.
Product Backlog Refinement
Ongoing activity of adding detail, estimates, and order to Product Backlog items. Not a required event but a required activity. Typically ≤ 10% of Developers' capacity per Sprint.
Key Numbers
| Thing | Value |
|---|---|
| Sprint length | ≤ 1 month |
| Scrum Team size | Typically 10 or fewer (whole team, including PO and SM) |
| Sprint Planning time-box | 8h per month of Sprint |
| Daily Scrum time-box | 15 min |
| Sprint Review time-box | 4h per month of Sprint |
| Sprint Retrospective time-box | 3h per month of Sprint |
| Backlog refinement effort | ≤ 10% of Developers' capacity |
Common Pitfalls
- Pretending to do Scrum — following the ceremonies but skipping the hard parts (self-management, true cross-functionality, rigorous Definition of Done)
- Weak Definition of Done → technical debt accumulates; design degrades over time
- Treating Developers as a sub-team → leftover habit from pre-2020 framing; everyone is one Scrum Team
- No Product Goal → Sprints become a treadmill with no long-term direction
- No Sprint Goal → Sprint Planning becomes "pick items off the list" instead of committing to an outcome
- Daily Scrum as a status report → it's a planning event for Developers, not a check-in with the Scrum Master
- Burndown charts misused → become management reports rather than self-management tools; drop them if they cause dysfunction
- Estimating in hours → encourages false precision; reduces team ownership
Scrum vs Waterfall
| Waterfall | Scrum | |
|---|---|---|
| Requirements | Finalized upfront | Continuously refined |
| Phases | Sequential | Blended into every Sprint |
| Feedback | End of project | Every Sprint |
| Risk | Late discovery | Limited to one Sprint |
| Change | Expensive | Expected and welcomed |