Skip to main content

Scrum Guide Update November 2017

November 7, 2017

Scrum Guide 2017Today (November 7th 2017) Ken Schwaber and Jeff Sutherland released an update to the Scrum Guide. The Scrum Guide is the definitive definition of Scrum, authored by Ken and Jeff, the creators of Scrum. The Scrum Guide describes the Scrum framework.  And, it is only 19 pages long. By keeping the definition short, it not only forces a clear focus, but also reminds everyone that it is not a methodology. Process emerges from use of the framework in response to the situation that the team is in. Because Scrum is focused on complex problems, defining a complete methodology is impossible. Instead Scrum provides a simple framework that encourages the right empirical process to emerge. That has allowed over 12 million people to practice Scrum today whilst solving VERY different problems in very different situations.

What is new in the November release of the Scrum Guide?

As always, the focus on any changes to the Scrum Guide were inspired by questions and issues posted on the Scrum Guide User Voice. This tool provides ‘empirical’ evidence from the community on what needs to change. Ken and Jeff review these comments along with their own experience they continue to gain by working with organizations implementing Scrum and decide on how or if the Scrum Guide should change. These changes do not change the core of what Scrum is, but instead provide clarity of definition, or usage. This update of the Scrum Guide includes:

  • Use of Scrum – From its Software Development Roots Scrum has evolved to be used in many different contexts. These contexts highlight the flexibility of Scrum and how an empirical process, values and focus on learning can help solve any complex problem. By adding this section Jeff and Ken provide a way for Scrum Masters not in software delivery to justify the use of Scrum. It helps resolve the age-old question ‘Scrum is only designed for software development’.
  • Refining the role of the Scrum Master – The Scrum Master is a key role in driving change within any organization by serving the team in their use of Scrum. This update of the Scrum Guide increases the clarity of the role by adding some words around what they do and how they do it.
  • The Daily Scrum – Perhaps the most popular event in any agile adoption but often this daily event becomes a status meeting instead of focusing on inspection and adaption. By changing the emphasis from the 3 questions and describing other ways the Daily can be run re-enforces the idea of inspection and adaption rather than status.
  • Time Box is a maximum length – It seems a simple idea, but for many a time box is the time, not the maximum. This leads to silly behavior, for example where everyone sits around for the 15 minutes for the daily, or insists that a Sprint Review takes x number of hours. The idea of a time box in Scrum is to focus the team, reduce amount of work being worked on and keep the rhythm of work.
  • Continuously Improve. Scrum is a framework that helps teams deliver work in a complex environment. That means the team should always be looking for better ways to work, to learn and to deliver more value. By adding the idea that the Sprint Backlog includes one high priority improvement the Scrum Guide reminds teams that improvement is NOT optional and that every team should have at least one thing they are trying to improve.

The changes to the Scrum Guide by Ken and Jeff not only improve the clarity of the Guide, but also encourages us to re-read it. Sometimes it is good to be reminded of that practice as it is surprising what little ‘idea nugget’ you might have missed before.

Scrum On.   


What did you think about this post?

Comments (8)


Alan Larimer
12:22 pm November 9, 2017

Highlighting that the framework can be applied beyond software is a nice addition.
The additional information and rewording for the Scrum Master role will be helpful to some.
Daily Scrum changes are a great step in a positive direction. Promoting a conversation over the three question format (3QF) or walking the board has been a challenging sell even to PSTs.
The need to further reiterate the definition of a time-box highlights one of many symptoms exemplifying that Scrum, for many, is not "Simple to understand" as advertised. :-)

The requirement to have "at least one high priority process improvement identified in the previous Retrospective meeting" on the Sprint Backlog creates some issues as it does not align with the definition of the Sprint Backlog.
It is not a Product Backlog Item (PBI).
It is not a part of the plan for delivering the Increment and realizing the Sprint Goal.
It is not a forecast of functionality.

The Sprint Backlog belongs solely to the Development Team therefore so would this process improvement item.
Changes are inspected and adapted during the Daily Scrum (for Development Team only).
Development Team works through the plan.
Only the Development Team can change its Sprint Backlog during a Sprint.
It is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint.


Julian Bayer
01:00 pm November 9, 2017

How is a process improvement not part of the plan to deliver the Product Increment?


Alan Larimer
11:55 pm November 9, 2017

It may be, but it might not always be. "Involve customers in the Sprint Review" "Create report XYZ to increase transparency" "Product Owner will work more closely with customers to determine value for PBIs for more effective prioritization" "Scrum Master will work with C-level to increase safety in raising organizational impediments" "Development Team will collaborate during the Sprint Review on what to do next" ...

What are your thoughts on the other points?


Olivier
01:55 pm November 13, 2017

Another big clarification is in the definition of Scrum : Scrum is a framework for developing, delivering, and sustaining complex products
And not only "developing and sustaining complex products" any more.
Few years ago, we had to build a bridge between coders and QA, then coders+QA and BA, and now the bridge with Ops is clear.


Alan Larimer
03:31 pm November 14, 2017

I also find the change from "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum." to "The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting." problematic as it interferes with self-organization. It was already difficult enough to keep many organizations from using it as a traditional status update meeting. Transparency is a pillar but the information discussed during the Daily Scrum should generally have no impact on anybody else. If it does, then it is the Development Team's responsibility to raise the concerns and issues.


Alan Larimer
02:31 pm November 23, 2017

@julianbayer:disqus What are your thoughts on my response and other points?


Bob Winter
04:04 pm January 3, 2018

Thanks for putting together what I think is a fair summary of what has changed. The process improvement point is needless hair-splitting - as long as teams regularly focus on and commit to improvement, they can put the work item wherever they like.


Alan Larimer
05:11 am June 8, 2020

Got 'em! Call up Robert Stack to revive Unsolved Mysteries for all those who vanish like this.