In November 2017, Ken Schwaber and Jeff Sutherland presented their revisions to The Scrum Guide™.
The recording of the webinar is available on Vimeo. It is just over 55 minutes long.
Here is a summary of the major changes:
1) Uses of Scrum
The new Guide now has an additional section titled ‘Uses of Scrum’ which stresses that Scrum is not just for developing software and tech; “Scrum has been used to develop … autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.”
In the video they propose that, if what you’re doing is in the complex domain, then Scrum is a great starting point.
2) The role of the Scrum Master
Ken and Jeff point out that the modern world is fast-moving in terms of change and pace of innovation, which generates grand visions for new opportunities.
In relation to this, they describe the Scrum Master as someone who is skilled at getting the team to turn such visions into something useful and, if necessary, identifying changes/improvements that need to be made in order to achieve this.
They say, “So a SM is the master of empiricism, small self-organising teams, lean thinking, and working with people to make that happen. It’s a very, very tough job.”
The new wording in the Guide is that the Scrum Master is responsible for “promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.”
It also extends the ways in which the Scrum Master serves the Product Owner by adding “Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.”
3) Daily Scrum
The Daily Scrum enables the Development Team to shift their focus and replan every day, if necessary, in order to achieve the Sprint Goal.
Previous Scrum Guides have advised that this should be done using three questions:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
This people-centred approach has its pros and cons, but some teams prefer to use other methods, such as focusing on the work instead (see walk the board). Therefore, the guide has been adapted to give the three questions as an optional approach.
The wording regarding attendance has also been changed from the Scrum Master enforcing a rule that only Dev Team participate 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.”
4) Timeboxing
What does the following sentence mean to you?
“Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.”
To me, that means that Sprint Planning can take anywhere up to a maximum of eight hours. So it could be one hour, or two hours, or three hours … It does NOT mean that it has to take eight hours.
Pretty simply, I know.
But according to Jeff and Ken, people appear to struggle with the words “maximum”. Apparently people think you have to use the full eight hours!
Ken’s response is pretty funny. It ranges from suggesting he buys everyone using Scrum a dictionary to the statement that “Scrum is not for people who can’t think.”
So the word maximum has been added. For example, Sprint Planning now says “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.”
Glad they cleared that up!
5) Continuous improvement
We frequently warn about running retros but not actually making any changes afterwards. The duo agree: “You need to take the actions from the retro and actually change/improve!”
The description of the Sprint Backlog in the new Guide has been extended to include: “To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”
Jeff and Ken admit to being unsure about making this change. If they state that people have to do self-improvement, does this mean it’s become a methodological procedure rather than a framework?
(L to R): Dave West (CEO and Product Owner at Scrum.org), Jeff Sutherland, Ken Schwaber.
There are also some smaller changes:
6) Sprint Goal
Wording changed from goal being crafted after Sprint Backlog agreed, to it being created during Sprint Planning.
7) Product Owner
There is clarification that the PO is “responsible for maximizing the value of the product resulting from work of the Development Team.”
It also clarifies that “No one can force the Development Team to work from a different set of requirements” rather than stating that nobody is allowed to tell the dev team to work on different requirements and that the dev team isn’t allowed to act on what anyone else says.
8) Dev team
A “Done” increment is required at the Sprint Review.
9) Sprint review
The Product Owner used to project likely completion dates … but now provides likely target and delivery dates.
10) Retrospectives
The guide now explicitly says that the retro is about improving work processes.
It also highlights that change should only happen if appropriate and “not in conflict with product or organizational standards.”
Those are the key changes to the Scrum Guide, but the video interview has two interesting snippets at the end.
First is a statement from Jeff Sutherland discouraging teams from only implementing parts of the Scrum Guide; “Implement it all, then tune to make it better.”
Secondly is when Ken Schwaber goes all Jedi on us: “We are really counting on you … so you can go out and do good things. Do it. … You are our hope.”
Click here to see the full version of the 2017 Scrum Guide.