Scrum Guide November 2017 Update

Ken Schwaber and Jeff Sutherland updated the official Scrum Guide on 7 November 2017 based on user feedback (or impediments!) from the Scrum community and their experiences implementing Scrum in practice.

I’ve listed all the updates below and attributed changes to the Scrum community member suggestions where I see correlation, although some suggestions have been tagged ‘complete’ and others have not, and at time of writing there is no official attribution of the changes from either Ken or Jeff.

Significant changes were made to:
– include additional clarity on the widespread use of Scrum,
– further refine the role of Scrum Master,
– increase flexibility around the practice of Daily Scrum, and
– reinforce that continuous process improvement must be part of every Sprint Backlog.

Here is a list of all the 2017 changes:

The (new) Uses of Scrum includes Continuous Deployment

Ralph Miarka suggested renaming ‘Development Team’ to ‘Delivery Team’ because Scrum is useful outside of software development, and in current practice the word ‘development’ often implies software ‘programing’ rather than including other necessary roles.

The new 2017 Scrum Guide added a whole new section clarifying the uses of Scrum and that “when the words ‘develop’ and ‘development’ are used in the Scrum Guide, they refer to complex work“.

Andy Brandt suggested emphasizing that software may be ‘released’ multiple times a Sprint rather than only releasing once per Sprint.

While not providing any detail and not using the words ‘Continuous Deployment’ the 2017 Scrum Guide includes a dot point that Scrum has been used to “Release products and enhancements, as frequently as many times per day;”

The (updated) Product Owner role

Henrik Kniberg suggested that the Development Team members must be allowed to work on requirements from people other than the Product Owner when it makes sense (like helping another team, or to work on another initiative) as long as they still respect the Sprint Goal.

Old 2016 Scrum Guide: “The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.”

New 2017 Scrum Guide: “The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.”

The (updated) Scrum Master role

Henrik Kniberg suggested updating the Scrum Master role to clarify the Scrum Master is a servant leader rather than a process enforcer.

Old 2016 Scrum Guide: “The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”

New 2017 Scrum Guide: “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.”

The 2017 Scrum Guide also added an extra dot point to another way the Scrum Master serves the Product Owner.

New 2017 Scrum Guide: “The Scrum Master serves the Product Owner in several ways, including:
– Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;”

The (updated) Product Increment

‘Anonymous’ user suggested making the Product Vision part of Scrum

New 2017 Scrum Guide: The following wording was added to the Product Increment section. “An increment is a body of inspectable, ‘Done’ work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.”

The (updated) Sprint Planning

Henrik Kniberg suggested clarifying when the Scrum Team craft the Sprint Goal because the 2016 guide appears to have conflicting statements that it occurs before and after selecting items for the Sprint.

Old 2016 Scrum Guide: “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.”

New 2017 Scrum Guide: “During Sprint Planning the Scrum Team also crafts a Sprint Goal.”

The (updated) Sprint Backlog

Agile PiMa suggested that improvements identified during Sprint Retrospective must be added to the next Sprint Backlog to ensure continuous improvement happens.

New 2017 Scrum Guide: “To ensure continuous improvement, the Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting.”

The (updated) Scrum Events

Henrik Kniberg suggested using the words ‘at most’ to clarify the time-box length of events is a maximum duration rather than specifying the events ‘must’ be an exact length.

Old 2016 Scrum Guide: “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
The Sprint Review is a four-hour time-boxed meeting for one-month Sprints.
The Sprint Retrospective is a three-hour time-boxed meeting for one-month Sprints.”

New 2017 Scrum Guide: “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
The Sprint Review is at most a four-hour meeting for one-month Sprints.
The Sprint Retrospective is at most a three-hour meeting for one-month Sprints.”

The (updated) Daily Scrum

The November 2017 update clarifies the reason for the Daily Scrum. I have not found who suggested this change.

Old 2016 Guide: “The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.”

New 2017 Scrum Guide: “The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work.”

Henrik Kniberg suggested allowing visitors to participate.

Old 2016 Scrum Guide: “The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.”

New 2017 Scrum Guide: “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.”

Richard Banks suggested removing the three questions in the Daily Scrum or making them optional because there are alternative approaches that work equally well and encourage the team to self-organize.

Old 2016 Scrum Guide: “During the meeting, the Development Team members explain:
– 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?”

New 2017 Scrum Guide: “The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
– 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?”

The (updated) Development Team

Henrik Kniberg suggested removing the wording ‘there are no exceptions to this rule’ because there are cases where exceptions do make sense.

Old 2016 Scrum Guide: “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule;”

New 2017 Scrum Guide: The wording “there are no exceptions to this rule” has been removed.

Improve Scrum by voting on ideas and suggesting a change

The Scrum Guide is periodically updated every 1 to 3 years. You can suggest changes to fix the Scrum Guide on the User Voice web site, and vote on suggestions made by others to improve the Scrum Guide.

Join the User Voice community!

Advertisements