In mid July, Ken Schwaber and Jeff Sutherland updated the Scrum Guide. The Scrum Guide is the “definitive rule book of Scrum and the documentation of Scrum itself” and the changes are intriguing to say the least.

A summary of the changes in Scrum Guide 2011 were made by Schwaber and Sutherland themselves on July 21st. Here they are summarised along with our thoughts.

Change #1: Development Team

“The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.”

We’re averse to siloing.

We worry this statement further pigeonholes very capable and intelligent people into a big “developer” bucket. We’ve been encouraging our development teams to read, watch and deeply understand everything from Eric Reis, Steve Blank, Ash Maurya, Dan North, Edward Tufte, Ryan Singer, David Anderson (the list goes on, and on).

Learning is everything.

We encourage our development teams to think outside of their development mind set. To be passionate, capable developers. But also be aware of and be able to contribute to the bigger picture.

Sure, some developers don’t want to.

The developers that do grow exponentially.

Change #2: Commitment

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that will change as more becomes known throughout the Sprint.”

Commitment is dead? Hooray!

It’s been dead to us for a long time (although in times of need, we have swung back to it on occasion).

This change is the biggest nod towards the Kanban and the Limited Work In Progress movement. And we fully agree. In fact, we’d go further, and argue that the ‘Development Team’ should spend as little time as possible putting together this “forecast”. If you use evidence, flow, and roughly-equal sized work items, you’ll end up with an exceptional measure of past progress for virtually no effort.

Change #3: Burndowns

“Scrum does not mandate a burndown chart to monitor progress. Scrum requires only that a) Remaining work for a Sprint is summed and known on a daily basis. b) Trending toward completing the work of the Sprint is maintained throughout the Sprint.”

Finally. I hope CSM’s around the globe don’t cry into their soup. If you use effective Visual Management you have never needed a “burn down” to see if you’re on target!

You (and all interested parties for that matter) can see progress with your own eyes by looking at where cards are on the board.

Measuring progress towards the end of an iteration is substantially less useful than  empirically measuring your performance over time: lead time, cycle time, & cumulative flow.

Grand, less busy work.

Change #4: Release Planning

“Release Planning is a valuable thing to do when using Scrum, but isn’t required by Scrum itself.”

This seems like another nod to the rising up of Kanban. Depending on your execution of Release Planning, we either fully support or have issue with this change.

Someone (product owner, product manager, whatever you call it) must be looking at regular, coarse grained goals – ideally through the eyes of Customer Development. That role has to and will continue.

If you’re of the “sit everyone in a room for 2 days and release plan every single item in a 300 item backlog” then yes, we fully approve. That approach should be put into a potato sack and eradicated.

Change #5: Single Backlog

“The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for delivering them. There is no longer a required concept of “Sprint Backlog items” although that technique can make a great plan. A self organizing Development Team always has a plan.”

This is a positive move towards “flow”. The dual concept of “Sprint Backlog” and “Product Backlog” has always been confusing for people first coming to Scrum. It is something we rejected long ago – a single “Backlog”, and you work through the top backlog items as quickly, smoothly and sustainably as possible.

Change #6: Ordered not prioritised

“The Product Backlog is “ordered,” instead of “prioritised,” providing flexibility to the Product Owner to optimize value in his or her unique circumstances.”

“Priority” is such an abstract term – you can prioritise by any set of rules or constraints you choose. Anyone who has performed the product owner role will know that the set of rules or constraints for “prioritising their backlog” is not as simple as just ROI, or just “business value”.

For us, an “ordered” backlog and a “prioritised” backlog have been synonymous for a very long time. In fact, since the dawn of anyone using Scrum. Think about it for a minute: anyone who’s ever had to manage development priorities will know they can’t prioritised by ROI solely. As soon as you do this your development team will say “we can’t build C before A, so we need to do A first”. A good development team will push back for business reasons also: “We could develop B in 1/2 the time of A, and we believe B will have more of an impact on monetization. Why wouldn’t we do B first”. This change in the Scrum Guide is very subtle.

The explanation given by Schwaber and Sutherland does little to clarify. This may just be a result of many practitioners understanding the concept of “ordering” backlogs for a long while.

One change in the comments from Schwaber and Sutherland is valuable. No two items can have the same “priority”: the backlog must be fully ordered. This is really first-baby-step stuff though.

Overall, it’s good to see the Scrum movement adopting and changing to the times.

What are your thoughts on the changes in the latest revision to the guide? Let us know: @14principles