Ken Schwaber and Jeff Sutherland, the creators of Scrum, have issued a new version of the official Scrum Guide, dated July 2013.

They have produced a video where they discuss the changes in the new Scrum Guide.

What I wanted to do in this article, was to get closer to the changes by listing the differences between the Scrum Guide 2011 and the Scrum Guide 2013 on a side-by-side comparison. This information is provided below without commentary.

All references to the old guide mean the Scrum Guide October 2011. All references to the new guide mean the Scrum Guide July 2013

General

When describing how to use Scrum, the old guide referred to “Specific strategies”. The new guide refers to “Specific tactics”

The various references to definition of Done have now been commonized as ‘definition of “Done”‘

The use of the word “goal” has been changed to read “Sprint Goal” (where appropriate).

The phrase “Sprint Planning Meeting” has been changed to “Sprint Planning”

Scrum Overview section

Replaced with “Definition of Scrum” (The definition remains the same as last edition of the Scrum Guide)

Scrum Framework section

Removed (though the exact same paragraph exists within the new “Definition of Scrum” section)

Definition of Scrum section

Changed “Scrum is .. Extremely difficult to master” to “Scrum is .. Difficult to master”.

Product Owner section

Changed “Ensuring the value of the work the Development Team performs” to “Optimizing the value of the work the Development Team performs”

Changed When referring to wanting changes in a Product Backlog item’s priority, the old guide referred to ” .. convince the Product Owner”. The new guide refers to ” .. address the Product Owner”

 Development Team section

The new guide emphasises that there are “no exceptions” to the rule that Scrum recognizes no sub-teams in the Development Team.

Part of the Scrum Master’s service to the Product Owner has changed:

Removed “Clearly communicating vision, goals, and Product Backlog items to the Development Team;”

Added “Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;”

Scrum Master Service to the Development Team has changed:

Changed “Teaching and leading the Development Team to create high-value products;” to “Helping the Development Team to create high-value products;”

Scrum Events section

Added “All events are time-boxed events, such that every event has a maximum duration. .. events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. ”

Clarity is also given to the duration of a Sprint: “Once at (sic) Sprint begins, its duration is fixed and cannot be shortened or lengthened.”

During the Sprint section

Changed: “No changes are made that would affect the Sprint Goal;” to “No changes are made that would endanger the Sprint Goal;”

Removed: “Development Team composition remains constant;”

Sprint Planning section

When referring to time-boxes for Scrum Events of less than one months duration, the phrase “proportionally shorter” has been replaced by the phrase “usually shorter”

Clarification is added that it is the Scrum Master’s responsibility to ensure that the event takes place and attendants understand its purpose.

Sprint Planning is no longer referred to as being in two “parts”. Instead, reference is made to two “Topics”, Topic One and Topic Two.

Part One was described as “What will be done this Sprint?” Topic One is now “What can be done this Sprint?”

The sentence “The Product Owner presents ordered Product Backlog items to the Development Team and the entire Scrum Team collaborates on understanding the work of the Sprint.” has been replaced with “The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.”

Part Two used to begin with the sentence “Having selected the work of the Sprint, .. ” but Topic Two now starts with “Having set the Sprint Goal and selected the Product Backlog items for the Sprint, .. ”

Product Owner involvement in Topic Two has been clarified to “The Product Owner can help to clarify the selected Product Backlog items and make trade-offs.”

Sprint Goal section

Added “The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.”

Removed “The Sprint Goal may be a milestone in the larger purpose of the product roadmap.”

Daily Scrum section

The meaning of the three questions addressed during the Daily Scrum has been clarified:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Changed ” .. the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal”

to

“Every day, the Development Team should understand how it intends to work together as a selforganizing team to accomplish the Sprint Goal ..”

Removed “The Daily Scrum is not a status meeting”

Sprint Review section

Added ” .. not a status meeting .. ”

Added “Attendees include the Scrum Team and key stakeholders invited by the Product Owner;”

Added “Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next;”

Added “Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.”

Sprint Retrospective section

Changed

“Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a “Done” Increment.”

to

“Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.”

Product Backlog section

This section has undergone major changes and readers are advised to read the new Scrum Guide. Highlights include:

Value is now an attribute of a Product Backlog item.

Product Backlog Grooming is now referred to as Product Backlog refinement

Monitoring Sprint Progress section

Removed “Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.”

Increment section

Added A new sub-section on Artifact Transparency:

“Artifact Transparency
Scrum relies on transparency. Decisions to to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results. The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.”

Definition of “Done” section

Added ‘If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the developer teams on all of the Scrum Teams must mutually define the definition of “Done.”’