Skip to main content

Inspecting the changes to the Scrum Guide – November 2017

scrum guide 2017

In the true spirit of Scrum, the Scrum Guide itself is regularly inspected and adapted. Below I look at the changes that were added in the November 2017 update.

View a summary of the Scrum Guide changes.

 

Uses of Scrum

Read the Uses of Scrum section of the Scrum Guide

Scrum isn’t just for software projects; it can be used for any situation where the requirements are complex and uncertain: it has been used to develop “software, hardware…schools, government…”.

This addition can help promote Scrum in organisations that might not think it’s suitable for them.

 

The role of the Scrum Master

Read the Role of the Scrum Master section in the Scrum Guide

Previously the language used in the description of the Scrum Master often caused it to be seen as an enforcer of rules. The guide has now changed so that rather than ensuring team members adhere to Scrum theory and rules, Scrum Masters help members understand Scrum theory, rules and values.scrum master

By including an understanding of the Scrum values, it gives team members a more holistic view of Scrum, rather than simply following the rules, which can be an important step in promoting self-organisation.

There is also a line added in the section Scrum Master Service to the Product Owner:

“Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.”

Generally, the goals, scope and product domain are areas of expertise for the Product Owner. But perhaps they have difficulty conveying this information to the rest of the team. The Scrum Master can assist with this, possibly looking at the best techniques to achieve this.

 

The Daily Scrum meeting

Read the Daily Scrum section of the Scrum Guide

The Daily Scrum is an opportunity to inspect progress towards the Sprint Goal and to inspect progress in completing work from the Sprint Backlog. Previous versions of the Guide prescribed three questions that development team members should answer in every Daily Scrum:

What did I do yesterday?Daily Scrum

What will I do today?

Do I face any impediments?

 

However, this has often led to the meeting turning into a status update, rather than an opportunity to both inspect and adapt.

The Scrum Guide now allows teams more flexibility around how they run their Daily Scrum meeting. They may choose to use the three questions, which are given as an example, or they may prefer a more discussion based format. Whatever is decided, the Development Team sets the structure.

 

The updates also provide clarification about who can attend the Daily Scrum. I think that previously, use of the word ‘participate’ confused matters and people were unsure about who could attend the meeting and who could speak in it.

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

2017 version: “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.”

Now it’s clear that it is up to the Development Team who can attend the meeting. If a third party is allowed into the meeting, they may speak and contribute as long as they don’t cause disruption.

 

Sprint Backlog

Read the Sprint Backlog section of the Scrum Guide

“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.”

This is probably something that most Scrum teams are doing already – in your Sprint Retrospective, identify how the Scrum process can be improved. Any improvements identified are then listed as a backlog item in the subsequent Sprint, ensuring that any identified improvements are implemented.

This ensures that improvements aren’t forgotten once the Retrospective has finished. The identified changes are fully transparent in the Sprint Backlog, ensuring their progress can be tracked.

 

 

Other minor changes

Timeboxes

The wording around timeboxes has been clarified to ensure that teams know they are maximum length for a meeting, but can also be shorter.

 

Product Backlog

Read the Product Backlog section of the Scrum Guide

2016 version: “The Product Backlog is an ordered list of everything that might be needed in the product”

2017 version: “The Product Backlog is an ordered list of everything that is known to be needed in the product”

This change makes a lot of sense and I’m surprised that it hasn’t been pointed out in the revisions document. We never fully know everything that might be needed in a product, so how can it be added to the Backlog? The update means the Backlog is a list of everything we know is required – as the team releases increments and obtains feedback, they will uncover additional features that are wanted. As they are discovered, the items are added to the Product Backlog.

 

Definition of Done

Read the Definition of Done section of the Scrum Guide

A new line has been added about how an expanded Definition of Done may cause increments that were previously Done, to no longer be Done, because they don’t meet the new expanded Definition of Done.

“New definitions, as used, may uncover work to be done in previously “Done” increments.”

I’m curious as to how this should be handled. Should the Product Backlog Items from the existing increment be re-added to the Backlog so they can be inspected and adapted to meet the new Definition of Done?

 

 

Conclusion

What are your thoughts on the changes to the Scrum Guide? Do they help to clarify things, or do they make the guide too prescriptive? Let me know in the comments below.