For most all games and activities, rules are published and considered separately from strategy. For example, the rules of chess say nothing about the various strategies that have evolved for playing the game; so should it be for the rule book of Scrum. With this distinction in mind I am proud to have been working with Ken Schwaber, Jeff Sutherland, Jim Coplien,  Scrum.org, and other advisors and contributors in producing a significant revision to the Scrum Guide.

The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on. Strategies for succeeding with Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those revising the Scrum Guide, this meant all tips, optional practices, and techniques should be removed from this document. This was done along with refining language to correct some common misunderstandings about Scrum.

While nothing about the Scrum framework itself is fundamentally changed, some long-needed clarifications were made. Each will likely deserve its own post in the future, so I will simply note them here.

• This is the role structure of Scrum with proper names shown. The careful observer will note the change from “The Team” to “Development Team”. This is the team of people performing the work of creating an Increment.

  

• Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team forecasts the work it believes will be done, and that forecast changes as more becomes known throughout the Sprint. To do otherwise is to ignore the cone of uncertainty at play during a Sprint.
• Burndown charts are not required. Neither Sprint nor Release nor Product Backlog burndowns. Those graphs are merely very effective at doing what is required, which is:
  • Remaining work for a Sprint is known and summed daily.
  • A trend of work remaining is maintained throughout the Sprint.
• Release Planning is not a required component of Scrum. Most organizations will certainly benefit from it, but it isn’t a core component of Scrum.
• The Sprint Backlog consists of the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of “Sprint Backlog items” although that technique is easy to implement and the items themselves can make a great plan.
• Backlogs are no longer said to be “prioritized”, but “ordered”. For some this is a non-issue, but for others it is a hill worth dying on. I’ll  write about why in a later post.

Although none of these notions are terribly radical, they help make clear the actual definition of Scrum. This clarification also makes clear complimentary practices that are useful, but will likely evolve separately from Scrum itself.

Read the updated Scrum Guide here.

David Starr