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.

Scrum Artifacts and how to ensure transparency

Let’s look at the Artifacts involved in Scrum – items or objects that provide Transparency and allow us opportunities for Inspection and Adaptation.

Product Backlog

The Product Backlog is an ordered list of all the features that might be required in a product. The Product Owner is responsible for the content, ordering and availability of the backlog.

The Product Backlog is a living artifact, that is, it is never complete. Items are removed from the backlog when they are selected for a Sprint. Items can be added to the backlog at any time, but are most commonly added during Backlog Refinement.
Initially the backlog holds only the best known requirements, but as the product and its environment change, items are added to the backlog.

The items in the Product Backlog are ordered by their priority. Higher ordered backlog items are usually clearer and better understood than items lower down the list. As items increase in priority, they are refined so that the Development Team have a better understanding of them.

The Product Backlog is an information radiator – a large, easy to see, display of data that is accessible to all. It allows individuals to see the upcoming features for a product and liaise with the Product Owner if they think an important requirement is missing. However, only the Product Owner can add items to the backlog.

 

Sprint Backlog

The Sprint Backlog consists of the Product Backlog Items selected for the Sprint, plus a plan of how to turn those items into an Increment.

During Sprint Planning, the Development Team decides which items it can implement during the Sprint, and these items are selected for the Sprint Backlog. The Development Team then formulates a plan on how to complete the work.

sprint backlog

As more information becomes available during the Sprint, the Sprint Backlog may change, with new items being added or unneeded items being removed. The plan to implement the items may also change.

The Sprint Backlog is owned by the Development Team. Only they can decide how much work can be completed in a Sprint and only they can change the Sprint Backlog.

 

Increment

The Increment is all the Product Backlog Items that have been completed during the current Sprint, plus all of the previous Increments. The Increment is a “Done” piece of software functionality that is potentially releasable to the customer. It is the decision of the Product Owner if the Increment is actually released or not. The Increment should allow the Sprint Goal to be satisfied.

 

Artifact Transparency

So that artifacts can be inspected, they must be transparent. This allows decisions based on the state of the artifacts to be made in order to control risk and increase business value. If artifacts are not sufficiently transparent, then they cannot be successfully inspected and risks may increase, costs may rise and decisions can be made incorrectly.

A good level of transparency has been achieved when the state of an artifact allows it to be easily inspected. This can be achieved by creating an open and blameless culture and ensuring that all members of the Scrum team are easily accessible. Stakeholders should be able to easily visit the Development Team in their office, as long as this doesn’t negatively affect the work of the team e.g. by stakeholders trying to add work to the Sprint without the consent of the Product Owner.

The Scrum Master works to ensure that all artifacts have the required level of transparency. They can do this by inspecting the artifacts, looking for patterns and noting differences between expected and actual results. For example, a Cumulative Flow Diagram can show where backlog items have been stuck in progress, causing a bottleneck. However, if a Scrum Master is made aware of an impediment, but this isn’t reflected in the cumulative flow diagram, this can indicate that the progress of a backlog item hasn’t been updated i.e. the Sprint Backlog doesn’t have full transparency.

Alhmodeus / CC-BY-SA-3.0

 

Scrum Events – The Sprint Review

The Sprint Review meeting takes place at the end of the Sprint. It allows the product increment to be inspected by the stakeholders and for the Product Backlog to be adapted by adding new items or rearranging existing ones.

The Sprint Review meeting is timeboxed to 4 hours, for a 1 month Sprint.

The meeting is attended by the whole Scrum Team, plus any stakeholders who have been invited by the Product Owner. First, the Product Owner explains which Product Backlog Items (PBIs) have been Done and which have not been Done.

Following this, the Development Team discusses what went well, any problems they had and how these problems were overcome.

Then the Development Team demonstrates the work that has been Done and answers questions. This is intended to be an informal demonstration, typically without the use of PowerPoint presentations. The presentation allows stakeholders to ask questions and give feedback on the increment.

sprint review meeting

During the Sprint Review, the Scrum Team should be able to demonstrate that the Sprint Goal has been met.

Following the demonstration, the Product Owner discusses the Product Backlog and may project likely completion dates based on the work completed so far.

The group takes a look at the overall timeline, budget and marketplace for the product, to give context for the next release.

 

The Scrum Guide also lists the following activities as part of the Sprint Review. In reality they are often moved to a separate event – Backlog Refinement.

  • The group collaborates on what to do next i.e. is the Product Backlog correctly prioritised or is it missing items?
  • A review of how changes to the marketplace have affected the work that needs to be completed next.

Definition of Done

When a product Increment is completed, we say it is Done. These are criteria that must be met before an increment can be released.

To know what Done really means, the Scrum Team must have a shared Definition of Done (DoD).

  • Separate teams that are working on the same product should share the same DoD
  • Separate teams working on separate products can have different DoD’s.

It may be that the organisation already has standards and policies which can be used as the DoD. But if these standards don’t already exist, then the Scrum Team must create one.

 

Example Definition of Done

  • Code compiles
  • Code Peer Reviewed by one other Developer
  • Tested by the Development Team
  • User Acceptance tested

Only when all of the above points are true, can the increment be called Done.

As the Scrum Team matures and adapts, it is likely that their DoD will change – it is likely to become more stringent, resulting in higher quality increments. See our teams’ current DoD.

 

Done vs Acceptance Criteria

Acceptance Criteria are used to define when a specific Product Backlog Item is complete – each PBI can have different acceptance criteria. While Done covers all PBIs in the increment.

 

Our Definition of Done

This post is just to record our teams’ definition of Done and track it as it changes over time.

Our Current Definition of Done

Code compiles

Code Peer Reviewed by one other Developer

Tested by the Development Team

User Acceptance tested

Approved by User Interface expert

 

 

Initial

Code compiles

Code Peer Reviewed by one other Developer

Tested by the Development Team

User Acceptance tested

 

Update 1

Approved by User Interface expert