Test Your Knowledge of the Scrum Guide™

Ken Schwaber and Jeff Sutherland,
authors of the Scrum Guide™

Among readers and non-readers alike, the list of books that people say they’ve read but actually haven’t read is a running joke. Among agile practitioners, Scrum Guide™, The Definitive Guide To Scrum: The Rules of the Game, developed and sustained by Ken Schwaber and Jeff Sutherland is the top book on that list.The book is available for free as a PDF from scrum.org, At 16 pages, it is light enough to require a paperweight (should you decide to print it).

I would advise anyone trying to practice scrum to look at the the Scrum Guide™ from time-to-time. Today I read it for probably the third time in two years, and I cannot believe the misconceptions to which I have fallen victim. Not that the Scrum Guide™ is the final or only word on Scrum (much less agile), but this book does a wonderful job of defining those certain things about Scrum that are immutable. You will also find clarification about issues where you or your team have decisions to make as a team. Aside from the rules of the game, there is wisdom and experience  in the words of the authors, as this book has been revised and re-released many times since 1991. On that basis alone, it is worth a look as you mature with the book.

Test your knowledge of the Scrum Guide™, July 2013.

How many of these 6 questions can you answer correctly? :

Q1: How many times does the Scrum Guide™ mention “software”?

Answer: 0.

This is interesting because it glosses over one of the oft-quoted Principles behind the Agile Manifesto: “Working software is the primary measure of progress.” As you read through, you can see that the rules of scrum have been wordsmithed, so that they can apply to any group of people making a “product” that is “released.” In place of working software, you will see references to “working product” (page 4). Scrum may have been invented by software people, but it can be applied to pretty much any work that involves an output of any kind.

Q2: What does the Scrum Guide™ say about Scrum Ceremonies?

Answer: Nothing.

But it does dedicate 5 of the 16 pages to “Scrum Events” (same thing, new name).

Q3: According to the Scrum Guide™, when is a Sprint Goal formulated?

Answer: It is created by the team during Sprint Planning. “After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal” (page 8).

I did not know that! In the past few months, I’ve spoken with several people about the idea of Sprint Goals, and I always assumed (as I think did some of my conversation partners) that the Product Owner created a Sprint Goal as part of Backlog Refinement. This document is full of little gems like this one.

Q4: How many times does the Scrum Guide™ mention Backlog Grooming?

Answer: 0.

The term is now Backlog Refinement.

Q5: How much time does the Scrum Guide™ suggest that the Development Team dedicate to Backlog Refinement?

Answer: “No more than 10% of the capacity of the Development Team” (page 13).

I can’t argue with that number, but it seems to be considerably less than our team perceives it to be. Agree or disagree, this nugget is a worthy team discussion point.

Q6: How many times does the Scrum Guide™ mention “Release Planning”?

Answer: 0.

There are three references to releasing product, but none to Release Planning. The document mentions “strategy” 0 times as well. It does mention “sprint plan” or “sprint planning” 15 times.

There is plenty written about the topic of release planning. One thing I found instructive was Mike Cohn’s blog Release Planning: Retiring the Term but not the Technique, Based on the comment warfare below that blog piece alone (87 comments), I hope the reader will understand that I consider myself well-advised simply express gratitude, because I now know that in 2012, Mike Cohn told us all to never, ever use that term again. “The term is no longer correct. We need a new term.”

Rest easy, release planners. Ken Rubin’s excellent book, Essential Scrum: A Practical Guide to the Most Popular Agile Process, “A Mike Cohn Signature Book” published in 2013, dedicates a whole chapter (23 pages) to release planning.

Notwithstanding the bombshell from the esteemed Mr. Cohn, I first decided to reread the Scrum Guide™ in search of an answer to my question about release planning. How does Scrum help Product Owners to take a long view of product development? Predictably (in hindsight), It turns out that the Scrum Guide™ does not address my question. Happily, Ken Rubin’s book does. Our team has struggled in part from focusing too much on Sprint Planning, taking very literally the notion of maximizing value on a sprint-to-sprint basis. We find that our planning is too myopic, too in-the-moment, and we lose track of the big picture. I need to do some more thinking and research as to how integrate long-term thinking into product development in Scrum.

Conclusions

1. I don’t need to tell you what getting 2 out of 6 correct or 6 out of 6 correct says about you. You know.
2. The global cottage industry that is Scrum continues to grow. That the Scrum Guide™ has been purged of every direct reference to software shows that the scrum business is looking to grow into other fields. The same can’t quite be said for  Scrum,org, the publisher of the Scrum Guide™, whose tagline remains “Improving the Profession of Software Development.”
3. I am reminded that when a reader of the Scrum Guide™ who works on scrum team also supports the agile enablement effort in a large software company, managing the training component of the agile transformation, the lexicographic hairsplitting of agile terminology by pontifical gasbags can grow tiresome.
4. LIke most great reference pieces, you can turn to it in times of confusion and within it find clarity and inspiration. You should keep it nearby and make a point to open it up once in a while.

Take a look at the Scrum Guide™ this week, whether or not you have read it before.