Warning: preg_replace(): Compilation failed: invalid range in character class at offset 4 in /home/customer/www/duncanhalley.co.uk/public_html/blog/wp-content/plugins/crayon-syntax-highlighter/crayon_langs.class.php on line 340
sprint retrospective – Duncan Halley's Blog 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


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?




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.

5 ways to be a great Scrum Master

Even the best Scrum Masters can often find ways to improve themselves, the team and the product. Below are a few tips that might help you become a better Scrum Master. Let me know in the comments what you think of these tips and feel free to add your own.

Listen to understand, not to reply

Listen, Understand, Act by Steven Shorrock / CC BY-NC-SA 2.0

Most people do not listen with the intent to understand; they listen with the intent to reply

– Stephen R Covey.


Most people only listen to others so that they can respond and get their own point across. This doesn’t allow the speaker to be truly understood, which might be vital to solving their problem or helping them. To be a true servant leader Scrum Master, you must put your own priorities at the bottom of the queue when listening to a team member. Only when you have fully understood someone’s issue, can you begin to help them.


Check in not just to find out about progress, but to become aware of impediments so they can be removed.

A great Scrum Master can check in with staff to get a progress update, without micro managing them. While getting an update of progress is fine, go further by offering to remove any impediments that may exist.


Celebrate and showcase the team’s success

A great Scrum Master ensures that the whole organisation knows about the team’s successes and the effort that was required by them to achieve that success. This not only motivates the team, but it also highlights the benefits of Scrum to the organisation. This is especially useful where the organisation has just started its agile journey and is expecting to see the benefits of it.

As Scrum Master, remember that you helped the team achieve their success, but they achieved it.


Get out and about to remove impediments

It’s easy for people to ignore the emails you send to them, but it’s more difficult to ignore you when you’re stood right next to their desk. When you need to remove an impediment, sometimes it can be more effective to go and see someone in person. Not only should you get a more prompt answer, but you’ll get an insight into their situation – perhaps they are facing an issue which in turn means that they can’t help with your issue.


sailboatHave a variety of Retrospective techniques

To ensure that Scrum Retrospectives don’t get stale, it’s important for the Scrum Master to have a variety of techniques/formats for conducting this meeting. Whether it’s Start, Stop and Continue; the Sailboat or something a little different such as Lego models or the Constellation Game, having a variety of formats not only keeps the Retrospective fun and engaging, but also provides opportunities for all team members to express their views.

Scrum Events – The Sprint Retrospective

The Sprint Retrospective allows the team to inspect itself and adapt the Scrum process for the next Sprint. The meeting is time-boxed to 3 hours and involves the whole Scrum team.

We look at how the last Sprint performed with regard to

  • People
  • Processes
  • Relationships
  • Tools

We also identify what went well and what could be improved. This items can also be ordered in terms of importance.

Finally, the whole team collaborates to create a plan for the next Sprint. This details how the improvements that have been identified, will actually be implemented.


The role of the Scrum Master is to see how the Scrum process can be improved so that the team can fully benefit from it. They encourage the team to improve their development processes so that they are more effective in the next Sprint.

Using what we have learnt from the Sprint Review and Retrospective meetings, the team can adapt the Definition of Done. For example, perhaps a stakeholder who turned up to the Sprint Review was colour blind and the team had not tested for sufficient contract on text colours. The Definition of Done can be adapted to the include accessibility testing of the subsequent increment.


Although it is one of the shortest Scrum meetings, it is also one of the most important. It allows us to utilise the empiricism that Scrum offers, so every Sprint we have a formal opportunity to inspect and adapt.

In subsequent posts, we’ll look at some of the techniques that can be used during the Sprint Retrospective in order to facilitate discussion and learning.

Sprint Retrospective technique – The Sailboat

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.


This technique uses a sailing boat as a metaphor for the team. The wind represents the things that are pushing the team forward, while anchors represent the things that are holding it back.

Using a diagram of the boat, team members use post-it notes to detail items in each of the above categories. They then stick them to the diagram in the appropriate place and read it out as they do so. You may find that common themes emerge, so related notes can be grouped together.

Once all the notes are posted, the team may choose to dot vote on those they think are most important. Usually each member has around 3 votes, which they can distribute however they wish.

The team then looks at the items under each heading. The ‘wind’ items are those that the team should continue doing. While the ‘anchor’ items should be addressed to remove the impediments. Perhaps ‘anchor’ items can even be transformed into ‘wind’ items?


Going forward

You don’t have to stick with the sailboat metaphor, there are many other objects you could use – cars, hot air balloons, a tree.

Sprint Retrospective technique – Timeline

Here I’ll look at one of the practical techniques you can use to promote discussion and learning in your Sprint Retrospectives.


A timeline retrospective allows the team to inspect how well the Sprint went, over a period of time. First, you will need a set of axes that represent each day of the Sprint. If you imagine the diagram below, but without the coloured cards.

Adding cards

Each team member will have cards in the colours above and they write down the events that occurred, on the appropriately coloured card. They then attach the card to the board so that it corresponds to the time that it occurred during the Sprint.


Drawing Conclusions

The chart provides an excellent visual representation of the Sprint and allows the team to easily see what went well and what could be improved. It also allows us to discover if certain events lead to other events – perhaps a significant event lead to a series of problematic events. Or there may be a cluster of good events around a particular time period.

Either way, the team can discussed these points and learn from them.

This chart could also be compared to the burndown chart for the Sprint. Does the velocity of the team increase when it experiences good events?



Based on the discussion, the team should identify actions they can take in order to improve in the next Sprint.