In 2010, Ken Schwaber and Jeff Sutherland published their first version of the Scrum Guide, as an attempt to define Scrum, and help practitioners understand the rules of the game. However, as Willem-Jan Ageling has recently posted here at Serious Scrum, this was nowhere near the first attempt to articulate the Scrum framework.
The first version of the guide was written between 2008 and 2010. Scrum was being used in industry for decades before 2008, but the guide in 2010 was Schwaber and Sutherland’s first attempt to distill the framework into a short, freely available document, a definition of sorts.
The conclusion, or ‘end note’ to the guide, added in July 2011, offers a hint to what the two authors are really striving for:
“Scrum is free and offered in this guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.” (Source: Scrum Guide July 2011)
Even in the foreword to the first edition, companies such as GE Medical and Fidelity Investments are acknowledged as early adopters of Scrum, and contributors such as Jeff McKenna, John Scumniotales, Mike Smith and Chris Martin, the late Mike Beedle, Martine Devos and Mike Cohn are among a long list of those making significant contributions to ‘What Scrum Is Today’.
“You call us the creators of Scrum? That’s really bold. I would call us the ‘parents’ of Scrum, because many many many people have contributed.” — Ken Schwaber (Source: Scrum Guide Update 2017)
However, the Scrum ‘Canon’ defined in the guide has changed a lot since 2010. In fact, there have been six separate iterations of Schwaber and Sutherland’s Scrum Guide. Have you kept up with all the changes since 2010? Indeed, do you know where Scrum might go next?
Don’t panic! You’re definitely not alone. This post might help. And the conversation is ongoing over at Serious Scrum. Have a read here, then come join us there for a chat if there’s anything you’d like to discuss.
2010 —Version 1.0
The Scrum Guide became freely available online in February 2010. Before then, since the early 1990’s in the context of organisational experiments, academic papers and books, and the professional conference circuit.
The guide in 2010 is an initial attempt to articulate the core components of Scrum for the first time, the ‘Must-Do’ parts of the framework. It’s fascinating to revisit that guide, even barely nine years on.
First, there are more than must-do components in the first iteration of the guide. Peppered through the guide are ‘tips’, or recommended practices, which future guides eliminated. However, empirical process theory was prominent right from the start.
Also laid out is the intention to use Scrum as “a framework within which complex products can be developed”, right from the first pages.
Of interest to me when I read this version of the guide was the jarringly informal reference to ‘Chickens and Pigs’, but also the reference to ‘Undone Work’. There was also an additional must-do meeting: the release planning meeting, which doesn’t make the cut any more, and the two burndown artifacts (Sprint and Release) are introduced as canon.
This really does explain to me why people outside scrum teams so often insist on the importance of the Sprint Burndown. I get it now! It was in the original guide! However, I can also understand why these became optional practices in future versions of the guide.
July 2011 — Scrum Defined, Grooming Introduced, Roles articulated
Even by only July 2011, there had been significant revisions to the guide. The shape, format and structure are a lot tidier. In addition, the Definition of Scrum is added.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
This simple elegant definition of Scrum still remains unchanged, alongside the ideas that the framework is simple to understand but difficult to master. How true is that!
The roles of Scrum Master, Product Owner and Development Team are much more clearly articulated in this version of the guide. In particular the role of the Scrum Master is elaborated in three sections, with service to the Product Owner, the Team and the Organisation appearing for the first time.
Grooming appears as a practice, and no longer just a tip, or a recommendation. While the practice is absolutely an essential part of the framework, the initial name of the practice is unfortunate, given the negative connotations associated with one meaning of the word. The subsequent revision of the Guide addresses this, but to Scrum practitioners all over the world, please stop calling it ‘grooming’. Urban dictionary can explain why! Spoiler alert: the reason why is unpleasant!
Perhaps the next most impactful change in the 2011 revision is also quite subtle. The Sprint Plan is a forecast, not a commitment. Scrum Masters, Product Owners, development teams and managers, please endeavour to understand and articulate this subtle but important difference, as it has a huge impact on how Scrum Teams operate. Effectively, it means that we will still demonstrate commitment to achieving the Sprint Plan, but we may need to inspect and adapt to changes along the way.
October 2011 — Minor Revision
This revision didn’t change a lot on first first viewing, certainly not when compared with the major revision of the same year. However, there is less emphasis now on the ‘rules’ of Scrum, and the last page from the July guide is removed. Interestingly, that page detailed the revisions made to the original 2010 document.
2013 — Refinement replaces Grooming, Daily Scrum Questions
This may seem like a point of language, but ‘refinement’ is soo much more appropriate than ‘grooming’. Thankfully, refinement replaced grooming in Scrum Guide canon in 2013.
In addition, the three Daily Scrum questions are refined and differ subtly from the most commonly heard versions you hear across Scrum Teams.
It is not ‘what did I do yesterday?’. It is ‘what did I do yesterday that helped the development team meet the Sprint Goal?’. In fact, all three questions relate to the team, and to the Sprint Goal. They are designed to help each member of the team evaluate his or her contribution to both the team and their goals every day. Amazing how the shorter versions can make things sound like a collection of individuals…
This version also refers to the idea that Product Backlog items can be ‘ready’ for a Sprint after refinement. This concept has been open to a lot of interpretation by Scrum Teams, perhaps most famously by Mike Cohn, and has also been debated here at Serious Scrum.
July 2016 — The Values!
The addition of the Scrum Values in July 2016 is perhaps most notable for revealing the fact that they were not in the Guide before this.
The Scrum Values (Respect, Commitment, Focus, Openness and Courage) were first articulated as far back as 2001, when Mike Beedle and Ken Schwaber collaborated on ‘Agile Software Development with Scrum’.
These values are now recognised as the life-blood of Scrum, and crucially important to helping Scrum teams deliver. Here at Serious Scrum, we love discussing and debating the Scrum values, and how they can be interpreted and applied. In my own opinion, it really is great to see them recognised as part of the canon.
If you want to learn more about why the values were added, check out this video. The first two minutes are also a clear articulation of why Schwaber and Sutherland put the guides together in the first place.
2017 — Impact
This version contains a bunch of changes, but my own personal favourite is the section on the uses of Scrum. The framework can be used by any team looking to solve complex adaptive problems.
Scrum proved especially effective in iterative and incremental knowledge transfer.
So many of the changes to this revision are around softening what is mandatory. For example, the famous ‘three questions’ in the Daily Scrum are now recognised as just one way to run this event. This recognises the fact that Scrum Teams don’t always slavishly follow the three question format. There are many great ways to run a Daily Scrum.
In addition, the purpose of the Daily Scrum now feels more about giving autonomy to the development team.
The description of the role of the Scrum Master is also subtly different in this revision. The scrum master is no longer responsible for “ensuring that the Scrum Team adheres to Scrum”, rather “helping everyone understand Scrum theory, practices, rules, and values.” This redefines the Scrum Master as coach, rather than policeman, and is a more accurate refection of how the role can be valuable in my own opinion.
Also, one of my favourite revisions: include an improvement item in every Sprint. As a Scrum Master myself, I found myself asking myself the question as I prepared this post: do I do that every Sprint, with every team?
I played the drums for years, and, when drummers practice, it is always a good idea to play the rudiments. In other words, if your core concepts are strong, you will be able to build on them and construct more elaborate patterns and phrases.
In revisiting the guides, Scrum Masters, Product Owners or Developers might be revisiting the rudiments of Scrum, but I think there is a lot of value in that activity. Personally, I learned a lot from preparing this post. I’m hopeful there was some learning in it for you too. Keep practicing those rudiments!
Scrum needs you! You can influence the future direction of the Scrum Guide. What changes would you love to see in the next revision of the Scrum Guide? Use your voice at this website.
For example, Serious Scrum’s own Willem-Jan Ageling has made a suggestion that the principle of Sustainable Pace is worthy of a mention in the guide. What do you think, would you vote for that?
Also, if you would like to discuss your ideas for changes, or elaborate further on any topics you see here, in any of the guides, or in the suggested revisions. there’s a #scrum-guides channel in the Serious Scrum Slack workspace.
Come join the conversation! You might influence the future direction of Scrum for the better.