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.
Uses of Scrum
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
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.
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
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 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.
“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
The wording around timeboxes has been clarified to ensure that teams know they are maximum length for a meeting, but can also be shorter.
2016 version: “The Product Backlog is an ordered list of everything that might 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
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?
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.