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

 

Kano Model – Product Backlog Prioritisation

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there may be features that would impress users but require very little effort to create.

Categories of features

Basic features – must be present in order for users not to be dissatisfied.

Indifferent features – Features that don’t affect a customers’ satisfaction one way or the other.

Linear features – the more of these there are, the more satisfied a user is.

Delighters – Features that are high up the satisfaction scale.

 

We can’t create only features that are high in satisfaction. This is because of the Functionality dimension, which represents how well a feature has been implemented, how much has been completed or how much it cost to develop.

Kano chart

The Four categories of Features

Basic/Mandatory features
Features that users expect to exist in a product are unlikely to score highly on satisfaction, but developing them can be costly. But if a basic feature doesn’t exist, users are likely to complain.

For example, a basic feature for a hotel would be ensuring 24 hour hot water. They require large expensive boilers (with associated fuel usage) that can supply instant hot water. The hotel must spend huge amounts on ensuring the hot water is available, but users will never get excited by it because it’s something they expect.

 

Indifferent features
Features that don’t really affect the satisfaction level of users. So no matter how much effort is put into developing them, it won’t make any difference to the happiness of your users. Because of this, think carefully about if you should be developing these features.

 

Linear features
The more you provide, the more satisfied users become. For example, battery life of a mobile device.

 

Delightful features
These are features that score highly on satisfaction, but may only take a small effort to create. If they aren’t present, a user is unlikely to complain. But if they are present, they will be delighted by the product.

Going back to the hotel example, providing guests with a free drink probably only costs a few pence, but is likely to score highly on satisfaction.

 

Delight changes to Basic

Over time, features that were originally classed as Delighters, will change to Basic features. For example, once users start to expect a free drink on arrival at their hotel, they will become dissatisfied if they were to no longer get the drink – it has become a basic feature.

 

Using the Kano Model to prioritise the Product Backlog

To discover how users see our products’ features, we conduct a Kano questionnaire. For each feature, we ask two questions:

  • Functional – How do you feel if this feature is present?
  • Dysfunctional – How do you feel is this feature is absent?

For each question, the user may answer with one of the following:

  • I like it
  • I expect it
  • I am neutral
  • I can tolerate it
  • I dislike it

Their answers can then be categorised using the following grid:

kano grid

Mandatory
L
inear
E
xciter
Q
uestionable
R
everse
I
ndifferent

So if a user answers the functional question with “Like” and the dysfunctional with “Neutral”, the feature will be classed as E, or Exciter.

You’ll notice we also have two new categories:

Questionable – these occur when the user gives conflicting answers e.g. like for both answers. This suggests there’s something wrong with what you’re asking.

Reverse – this suggests the user actually wants the opposite of what we’re suggesting for the feature.

 

Once your users have completed the questionnaire, you can aggregate the results. For each feature, add up the responses in each Kano category. The category for a particular feature is the one with the largest amount:

kano results

So we can see that login using Facebook is a Mandatory feature, upload a photo is Linear, and share photo with friends is an Exciter.

When it comes to prioritising the Product Backlog, you need to include the Mandatory items as your highest priority, followed by Linear and then Exciter.