This is in the new Scrum Guide

15 November 2017
| |
Reading time: 3 minutes

On 7 November 2017, the two fathers of Scrum, Ken Schwaber and Jeff Sutherland, presented a new version of the Scrum Guide. The previous version had been issued in July 2016. This latest version is available in English. I would like to use this blog entry to briefly highlight the key changes.

New chapter: Uses of Scrum

This explicitly explains that Scrum can be used not just for the development of software, but also for hardware, networks, cars, buildings, schools, government, marketing, business operations, in fact basically for almost everything you need in daily life.

In essence it involves small, multi-functional teams working collaboratively to solve complex problems, with the aim of developing or further developing a product or service in order to bring benefits to a large number of users.

Strengthening of the Scrum Master role

The Scrum Master is responsible for the promotion and support of Scrum, as defined in the Scrum Guide. The Scrum Master does this by helping everyone in the organisation understand and embrace the Scrum theory, practices, rules and values.

Daily is an Inspect & Adapt

Ken and Jeff again emphasise that the Daily is not a Status Report. Its focus is on determining whether or not the sprint goal can be achieved and how to eliminate possible obstacles. It is a brief Inspect & Adapt opportunity, whereby it is also entirely possible to change the plan.

The structure of a Daily is defined by the development team and can also be done without a Scrum Master.

Time boxes are a maximum and not a guide value

Time boxes are to be understood as a maximum, not as a specification. It would be ideal if less than half this time were taken, so that, for example, planning might also be completed in less than two hours.

Retrospective improvements in the Sprint Backlog

By the end of the sprint retrospective, the Scrum team should have identified improvements that it can implement in the next sprint. My personal recommendation in this regard is to list the implementation of these enhancements as high-priority backlog items in the Sprint Backlog.

DevOps and Releases

Scrum does not rule out DevOps, but in fact welcomes this. In other words, a DevOps team can also work pursuant to Scrum. DevOps supports the agile idea of delivering valuable software on a regular basis. However, Scrum does not state that a release should be made after each sprint, so this can be done independently of the sprint.

And what has changed in detail?

More information is available here. A direct comparison between the two documents has been made in a clear, easily comprehensible manner by Scrum Guide Nerd Peter Gfader.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »