The Scrum Guide contains the official definition of Scrum, a lightweight framework for developing and sustaining complex products. Authored by Ken Schwaber and Jeff Sutherland, the Guide provides the rules that bind together accountabilities, events, and artifacts. Marketing teams can apply this framework to manage complex campaigns that require frequent inspection and adaptation.
What is the Scrum Guide?
The Scrum Guide is the authoritative source document that defines Scrum completely. Ken Schwaber and Jeff Sutherland, the originators of Scrum, wrote the first version [in 2010] (Agile Academy) to help people worldwide understand the framework. [First co-presented at the OOPSLA Conference in 1995] (Agile Academy), Scrum evolved into its current form defined in the Guide.
Ken Schwaber and Jeff Sutherland maintain the Scrum Guide independently of any company or vendor on a brand-neutral site. [Translated and available in over 30 languages] (Scrum.org), the Guide describes the framework as immutable. Scrum exists only in its entirety and functions as a container for other techniques. Implementing only parts of Scrum is possible, but the result is not Scrum.
A new version of the Scrum Guide was released [18 November 2020] (Scrum Alliance). This 2020 version updates the framework while maintaining its core empirical foundation.
Why the Scrum Guide matters
The Scrum Guide matters because it establishes empiricism and lean thinking as the foundation for managing complex work. Knowledge comes from experience and decisions based on observation.
- Reduces waste. Lean thinking focuses on essentials and eliminates unnecessary processes.
- Controls risk. The iterative, incremental approach optimizes predictability through regular inspection.
- Enables self-management. Teams internally decide who does what, when, and how, improving focus and consistency.
- Creates transparency. Artifacts like the Product Backlog make work visible to all stakeholders.
- Supports multiple domains. Though Scrum has roots in software, the Guide now addresses any complex work including research, analytics, and creative projects.
How the Scrum Guide works
The Scrum Guide defines Scrum through three formal elements: accountabilities, events, and artifacts. These elements support the empirical pillars of transparency, inspection, and adaptation.
The Scrum Team
The fundamental unit is a small Scrum Team. [Typically 10 or fewer people] (Agile Academy), the team is cross-functional and self-managing. It contains one Product Owner, one Scrum Master, and Developers. No sub-teams or hierarchies exist. The team focuses on one Product Goal at a time.
The Sprint
Sprints are fixed length events of one month or less that serve as the heartbeat of Scrum. A new Sprint starts immediately after the previous one ends. During the Sprint, no changes endanger the Sprint Goal, quality does not decrease, and the Product Owner may clarify and renegotiate scope as more is learned.
Events within the Sprint
All work happens within Sprints through four formal events:
-
Sprint Planning initiates the Sprint. [Timeboxed to a maximum of eight hours for a one-month Sprint] (Agile Academy), the team addresses why the Sprint is valuable, what can be done, and how the work will be performed.
-
Daily Scrum inspects progress toward the Sprint Goal. [This is a 15-minute event for the Developers] (Agile Academy), held at the same time and place every working day. The Developers create an actionable plan for the next day.
-
Sprint Review inspects the outcome. [Timeboxed to a maximum of four hours for a one-month Sprint] (Agile Academy), the Scrum Team presents results to stakeholders and collaborates on what to do next. This is a working session, not a presentation.
-
Sprint Retrospective plans ways to increase quality and effectiveness. [Timeboxed to a maximum of three hours for a one-month Sprint] (Agile Academy), the team inspects how the last Sprint went regarding individuals, interactions, processes, and tools.
Artifacts and commitments
The Scrum Guide defines three artifacts, each with a commitment to reinforce empiricism:
- Product Backlog: An emergent, ordered list of what is needed to improve the product. The commitment is the Product Goal, describing a future state of the product.
- Sprint Backlog: Composed of the Sprint Goal, selected Product Backlog items, and the actionable plan for delivering the Increment. The commitment is the Sprint Goal, the single objective for the Sprint.
- Increment: A concrete stepping stone toward the Product Goal. The commitment is the Definition of Done, a formal description of the state when the Increment meets quality measures.
Best practices
Keep teams small. [Maintain teams of 10 or fewer people] (Agile Academy) to ensure nimble communication and productivity. If teams grow larger, reorganize into multiple Scrum Teams focused on the same product and Product Owner.
Respect the timeboxes. Strictly adhere to the time limits for events. Shorter Sprints generate more learning cycles and limit risk.
Establish a clear Definition of Done. Create transparency by providing everyone a shared understanding of what work is complete. If the Definition of Done is organizational, all Scrum Teams must follow it as a minimum.
Adapt immediately. The team should adjust the moment it learns anything new through inspection. Delaying adaptation increases deviation and risk.
Maintain the Sprint Goal. During the Sprint, collaborate with the Product Owner to negotiate scope without affecting the Sprint Goal if work turns out different than expected.
Common mistakes
Mistake: Changing the core design of Scrum or leaving out elements. This covers up problems and limits benefits, potentially rendering Scrum useless. Fix: Implement Scrum in its entirety. The framework is purposefully incomplete, but the defined elements are mandatory.
Mistake: Skipping events or treating them as optional. Fix: Operate all events as prescribed. Failure to do so results in lost opportunities to inspect and adapt.
Mistake: Allowing the team to exceed 10 people. Fix: Split into multiple cohesive Scrum Teams sharing the same Product Goal, Product Backlog, and Product Owner.
Mistake: Treating the Sprint Review as a status presentation rather than a working session. Fix: Collaborate with stakeholders on what to do next based on what was accomplished.
Mistake: Inspection without adaptation. Fix: Make adjustments as soon as possible when aspects deviate outside acceptable limits.
Examples
Example scenario: A marketing team uses Scrum to manage a product launch campaign. The Product Backlog contains items like "Create landing page copy" and "Design email sequence." They select a two-week Sprint. The Sprint Goal is "Generate 500 qualified leads through the new campaign assets." The Daily Scrum keeps the three-person team aligned. At the Sprint Review, they demonstrate the landing page to stakeholders and decide to adjust the call-to-action based on feedback. The Retrospective identifies that the handoff between copywriting and design caused delays, so they adjust their process for the next Sprint.
Example scenario: A content agency adopts Scrum for client work. The Product Owner orders the content calendar into the Product Backlog, prioritized by client deadline and SEO impact. The Scrum Master removes impediments like unclear client briefs. The team produces Increments of value (published articles) every week, meeting their Definition of Done which includes SEO optimization and editorial review.
FAQ
What is the difference between the 2017 and 2020 Scrum Guide versions? The 2020 version was released in November 2020 and contains updates to the framework. Resources are available that describe specific changes between the 2017 and 2020 versions. The current version emphasizes the Product Goal and clarifies accountabilities within the Scrum Team.
Is Scrum only for software development? No. While Scrum has its roots in software, the Guide now addresses any complex work. Developers, researchers, analysts, scientists, and other specialists apply Scrum. The term "developers" refers to anyone creating the Increment, not specifically software engineers.
How long should a Sprint be? Sprints are fixed length events of one month or less. Shorter Sprints can be employed to generate more learning cycles and limit risk to smaller timeframes. The Scrum Guide recommends trying Scrum as written and adjusting Sprint length based on empirical observation.
Who can cancel a Sprint? Only the Product Owner has the authority to cancel a Sprint, and only if the Sprint Goal becomes obsolete. Cancellation incurs costs and is rare.
What happens if we cannot complete everything in the Sprint Backlog? The Sprint Backlog is a plan by and for the Developers. If work remains unfinished, it typically returns to the Product Backlog for future consideration. The team collaborates with the Product Owner to negotiate scope within the Sprint without affecting the Sprint Goal.
Can we use Scrum without a Scrum Master? No. The Scrum Guide requires a Scrum Master to foster an environment where the framework operates. The Scrum Master is accountable for establishing Scrum as defined in the Guide and for the team's effectiveness.
