Commentary to the Scrum Guide

The Scrum Guide is the foundational document of Scrum. Brief, succinct and clear. But do we really understand it? The Commentary to the Scrum Guide is here to help.

The history of Scrum – as a framework highly suitable for software development – started in 1995 when Ken Schwaber and Jeff Sutherland introduced their concept at the OOPSLA conference. Even though both authors had been quite prolific, a formal ‘Rules of the Game’ was not available until 2010. By then, numerous organizations adopted Scrum without firm guidance, often breaching major Scrum rules and Agile principles. The then quasi-official body, Scrum Alliance was more engaged in certification programs than in strengthening the standards and clarifying the framework for a common understanding. It was time to publish the quasi-official Guide to help the practitioners understand what ‘Scrum is’, what ‘Scrum is not’ and what fits Scrum. The Scrum Guide (hereafter: the Guide) is the cornerstone of the Scrum framework, the most popular agile choice of organizations.

Scrum Guide History

With regard to the numerous changes the Scrum Guide saw between 2010 and 2020, the original 2010 version and the 2017 version both appear at the bottom of every page, they provide not only history but often extra explanation and context to the discussed topics. Why these two? The 2010 version is the original one. The 2011 version brought significant changes, the authors removed the tips, tools and practices. The 2011-2017 versions are structurally similar with the 2017 being the most mature and polished one. The 2020 version was a complete overhaul of the document.

The consecutive updated editions of the Guide are heading toward an ever more abstract approach to defining Scrum. The current version is noticeably more professional than the early versions were. It provides more clarity yet leaves more room for teams on their journey to implement tools, techniques, and processes that best fit their environment. On the other hand, the Guide is very abstract and very dense. Every sentence, every expression or word choice delivers an important message, sometimes almost hidden from the reader. Brevity is not a shortcoming of the Guide, though, since it is not its mission to teach agile techniques or even the concept of agile. For that purpose, there are endless sources on the market. Books, blogs, articles, studies, courses, videos, and podcasts aim to educate their consumers about Scrum. However, a detailed explanation of The Scrum Guide has not been available – until now!

Commentary to the Scrum Guide

The mission of the Commentary to the Scrum Guide is to cover the gap. The reader is provided with the commented (or annotated) version of the Guide. Explanations and examples are directly added next to the original chapters, casting light on implicit statements, hidden connections, and often misunderstood sections. Every article has the same, simple structure: a chapter of the Guide (with the subheading: The Scrum Guide) and the corresponding commentary (with the subheading: Commentary). The end product is the Commentary to the Scrum Guide. Though the text strives to provide all the important details, it is still concise. To compensate for this, links are provided to pages detailing agile techniques in more depth. These pages are also accessible under the Agile Terminology menu.

Tools and techniques described in the commentary are illustrations only. However, as the Guide states, Scrum functions well as a container for agile techniques. Whether it is managing the product backlog, performing business analysis, or implementing a solution, teams can choose from a wide variety of agile techniques. The commentary illustrates the Guide with the most commonly used techniques.

Please note that The Scrum Guide is the intellectual property of Ken Schwaber and Jeff Sutherland. The Commentary to the Scrum Guide presents the original text without changes as the Attribution Share-Alike license of Creative Commons permits and requires. The Commentary to the Scrum Guide is a ‘third party’ interpretation of Scrum, explaining all the chapters without contradicting any books, leaflets, papers, posts, or published speeches of the authors of the Guide.

Who is it for?

Suitable for all audiences. Ideal for exam preparation and for deepening our understanding.

For readers not yet experienced with Scrum, the Interactive Scrum Map is worth visiting (seen on the diagram below) before reading the Guide. The definitions are from the Scrum Guide.

Scrum Interactive

For more information, click an entity!

Scrum Interactive
Product Owner Scrum Master Developers of the Scrum Team Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Product Backlog Sprint Backlog Increment Stakeholders - Not a role in Scrum The Scrum Team

Product Owner

"The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals."

Scrum Master

"The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization."

Developers of the Scrum Team

"Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work."

Sprint

"Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints."

Sprint Planning

"Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. Sprint Planning addresses the following topics:

  • Topic One: Why is this Sprint valuable?
  • Topic Two: What can be Done this Sprint?
  • Topic Three: How will the chosen work get done?"

Daily Scrum

"The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers."

Sprint Review

"The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed."

Sprint Retrospective

"The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter."

Product Backlog

"The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal."

Sprint Backlog

"The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint."

Increment

"An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable."

Stakeholders - Not a role in Scrum

Stakeholders do not have a role in Scrum, however, they play an important role in running the organization, planning, implementing and using the product, etc.

The Scrum Team

"The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal."