Scrum Guide Update – Scrum’s Five Values

You might not have noticed, but The Scrum Guide was updated recently (July 2016) for the first time in three years. The changes aren’t big in terms of word count, but they are significant. So I decided I needed to update my own description (1, 2) of the Guide’s evolution.

Cumulative Flow Diagrams

Let’s deal with the smallest change first. Cumulative Flow diagrams (CFDs) have been added to the list of example ‘information radiators’ that a Scrum team might use to track its progress towards its Sprint Goal. CFDs are associated popularly with Kanban – though I think they started life in Feature Driven Development – so it might be a bit of a surprise to some to see them mentioned alongside burndown charts and task boards. Don’t worry though, it is just that – a mention. You don’t have to use any specific charts or diagrams to use Scrum, so there’s nothing fundamental being indicated here.

Scrum Values

The big change is a paragraph that reintroduces the five values of Scrum. They’ve been around since 2002 at least when they were described in a book by Ken Schwaber and Mike Beedle (3). They’ve never really gone away. Although they have not previously been mentioned in The Scrum Guide they have always been included in the curriculum for the Scrum Alliance’s Certified Scrum Master and Certified Scrum Product Owner courses, for example.

So why now? Scrum has become a victim of its own success, but many implementations of it are sterile. They are not productive. They are not effective and, frankly, they are no fun. As Ken Schwaber has said recently, it is not enough to apply the rules, you have to live Scrum. The five values of Scrum have to infuse everything you are doing, or trying to do, with the framework if it is to do its job.

Here are those values:


The first is commitment. Scrum teams have to commit to a goal. This is hard – not least because commitments can be abused. In fact, the term was deliberately removed from a previous revision because it was being misinterpreted as a guarantee, and some managements were holding teams to task because they were not meeting their “commitments”, even if the cause was external. Teams forecast where they expect to be at the end of a Sprint. They cannot guarantee it because new information might emerge even in such a short duration. When a Scrum teams says, however, that they expect to deliver a specific Sprint Goal, their commitment is to do everything they can to achieve it.


The second is focus. As team members and as individuals, we must do our job. We must focus on the Goal we have committed to, and must not be distracted by anything else. Producing a viable product increment at the end of every single Sprint is hard work. It requires attention. If the team keeps its focus, and remembers it has the authority to do whatever is needed to deliver working product, great things can be achieved.


The third value is openness. Scrum keeps things open and visible. Transparency is required for Scrum to work, and its mechanisms are designed to heighten visibility. Outcomes are visible in the Sprint Review. What the team is working on is revealed daily, at the Scrum. Progress can be tracked by anyone with an interest in the product. As Schwaber and Beedle wrote, “Scrum removes the ability to dissemble”. There is nowhere to hide. There is nothing to pretend about.


Value number four is respect. Scrum teams are fully cross-functional. People with different functional and personal backgrounds come together with all the skills – between them – necessary to create the product. Mutual respect for these varied experiences is a prerequisite for the team to function correctly. When problems are identified a strong team “diverges” to explore different options, and then converges on a solution. In the absence of mutual respect it is more likely that a less than optimal way forward is chosen. Conflict in the team can be used positively to everyone’s benefit if differences are respected, otherwise it can be the source of major, repeated dysfunction.


The final one of the values is courage. With self-management comes responsibility. Scrum teams have to have the courage to take on those responsibilities – and to be accountable for the choices they make when carrying them out. They have to have the courage to say ‘No’ when, perhaps, managers or even Product Owners try to push more work onto them than they can handle. They have to have the courage to be agile in the face of external pressures pushing them in a different direction.

The addition of the five values means that this latest version of The Scrum Guide is the first to have expanded rather than subtracted what was in previous editions. The intent is still to keep the framework to a minimum so that the Scrum team has the maximum amount of space to decide itself how to do its work. But a gap has been filled. Something that was always implied has now been made explicit. If you are a Scrum Master, or a member of a team that is struggling, it is worth doing a sense check to see if they are just following some rules mechanically, or whether they are really are acting in the spirit of Scrum too.

(1 )


(3) Ken Schwaber and Mike Beedle. Agile Software Development with Scrum. Prentice-Hall.2002

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.