Vincent Costel

2017 Scrum Guide

A few weeks ago, Ken Shwaber and Jeff Sutherland, creators of Scrum, released an updated version of the official Scrum Guide.

Around 2008-2009, a project I was working on was scraped after months of development. This was a disheartening experience. If the problems had been detected earlier, we could have corrected the course of the project, or simply abort it without wasting so much time. I took interest in Agile software development around that time and started by reading the 2004 book Agile Project Management with Scrum by Ken Schwaber. Then, after some convincing by a few colleagues and me, my company hired a coach who taught us Scrum and Agile principles in general.

I keep practicing Scrum to this date, but when the 2017 Scrum Guide was announced, I glanced at the revision history and realized that I never actually kept pace with the changes that were introduced to the Scrum framework along the years.

So here it is: The 5 things I learned or relearned while reading the 2017 edition the Scrum Guide.

1) Development Teams do not commit to completing the work planned during a Sprint Planning Meeting #

When I was first taught Scrum, this commitment by the team to deliver all the Sprint Backlog items was an important principle. I don't know if it was an actual rule of the framework at the time, or just a widespread interpretation, but this was removed/reworded in the 2011 Scrum Guide and instead:

The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.

This is something we've been doing for a long time anyway, because even with short sprint there is still a lot of uncertainty. Also, it is more in line with the "Inspection" and "Adaptation" pillars of Scrum.

2) The importance of the Sprint Goal #

The Sprint Goal is an objective set for the Sprint [...]. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.

Instead of just having a laundry list of backlog items to implement, the Sprint Goal represents what the Development Team must accomplish during the Sprint.
Every day, the Daily Scrum is used to monitor the progress towards the Sprint Goal. Also, during the Sprint, "no changes are made that would endanger the Sprint Goal."

3) A self-organizing team always has a plan #

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

I like this idea that the Sprint Backlog is not just a list of selected Product Backlog items. During the second phase of Sprint Planning, you must come up with a flexible plan for delivering the goods.

Also, the Daily Scrum should not so much be about reporting what was done during the last day, but should instead be seen as planning event for the next 24 hours.

4) Sprint Review is more that a demo #

This one surprised me. Usually we do a demo of the Increment at the end of the Sprint just before doing the Sprint Retrospective. During the demo, we gather feedback that can be used as input for the next Sprint Planning.
However, the Scrum Guide goes a bit further:

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.

So during the Sprint Review, the team should review the current state of the product and examine what changed during the Sprint in terms of timeline, features, budget, etc. Then they collaborate on what to do in the next Sprint.

5) Put Retrospective items in the sprint backlog #

This bit was added in the latest version (2017).

To ensure continuous improvement, the Sprint Backlog includes at least one high priority process improvement identified in the previous Retrospective meeting.

This is more prescriptive than before but I like it. It is hard to track the implementation progress of improvements identified during Sprint Retrospective, so we might as well put them in the Sprint Backlog to keep an eye on them.

So Scrum is still Scrum, but this was still a good opportunity to freshen my Scrum knowledge and renew my interest in practicing agility.