By Nathan Donaldson
Tags: Agile
Here at Boost we’ve been reviewing the updated Scrum Guide by Jeff Sutherland and Ken Schwaber, released in July (you can download the guide at Scrum.org)
Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.
In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:
The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.
Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.
Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.
… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.
We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.
A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.
The Scrum Guide’s section on the product backlog really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.
Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!
More reviews of the differences between the 2011 Scrum Guide and earlier versions:
