What the Heck Is the “Scrum Guide”?

In my last post I wrote about an important change in the Scrum Guide concerning the Daily Scrum.

After I received some questions about the Scrum Guide itself, I decided to dedicate a post to this topic: what is the Scrum Guide, who writes it, and why has it changed.

The Beginning

If you want to understand why the Scrum Guide exists, you have to go a few years back. In 2008, it was quite unclear what “Scrum” actually meant. There was little orientation besides the book “Agile Project Management With Scrum”, which dated back to 2004 and was obviously outdated and incomplete in some respects.

After their certification, Scrum Trainers could convey whatever concepts they deemed appropriate. This lead to increasingly diverging interpretations and descriptions of Scrum. Some people used Scrum to mean any kind of incremental process. Others continued to use the waterfall-approach enhanced by a 15-minute status meeting every morning – and called this “Scrum”. Still others did analysis sprints, followed by development sprints, followed by testing sprints – and also called this Scrum. Those who knew better cried “Oh no, but that’s not Scrum!” But there was no reference they could point to.

In this situation the two creators of Scrum, Ken Schwaber and Jeff Sutherland got together, and during the year 2009, they wrote a document that contained a concise definition of Scrum – the so-called “Scrum Guide”. And even though they decided to follow separate paths in the years to come – Jeff is still Certified Scrum Trainer in the Scrum Alliance, while Ken has founded a new organization to spread Scrum called scrum.org – the Scrum Guide is still the definite, official source for what is meant by Scrum, for both organizations.

In the following years severeal new versions of the Scrum Guide have been published that contained new insights, improvements and adaptations of Scrum to market needs. Each time the Scrum Guide got a little “lighter” and focussed even more on its essentials as a framework to successfully create products in a complex world. For example, in 2011 they removed the necessity of creating a Sprint-Burndown. Instead the Scrum Guide now mandates that the Development Team should make their progress clearly visible on a daily basis.

Latest Changes to the Scrum Guide

After the release of July 2016, surprisingly there was another release after not even 1½  years. So, what has changed? The good news is: not much, but enough to have a closer look:

  • First of all: Content and participants of the Daily Scrum have changed. The details I have already described in my previous post Daily Scrum News: Beyond the Three Questions.
  • In addition, a section about the Scrum Master has changed, creating more clarity about his role. Now, his job is to promote and support Scrum as defined in the Scrum Guide. And he helps everyone understand Scrum theory, practice, rules, and values.
  • It is made explicit that Product Backlog Items typically contain test descriptions that will prove its completeness when done. This is an abstraction of the acceptance criteria or conditions of satisfaction of XP user stories.
  • The concept “Sprint increment” is explained in a way that gives additional support when Scrum is used for hardware development: it is a described as a body of inspectable, done work that supports empiricism at the end of the Sprint.
  • Now, the Sprint Backlog contains at least one high priority process improvement identified during the previous Retrospective.
  • The Scrum team can define the Sprint Goal before or after selecting Product Backlog Items during Sprint planning. It is enough that the Goal is defined during the event.

Even though you may call these changes fine-tuning maybe with the exception of the changes to the Daily Scrum, it still makes sense to read new release with care, especially if you took  your CSM course some years ago, or if you only got to know Scrum in a version that has been “adapted to the local context”.

The current version of the Scrum Guide can be found on this website:


Or have a look at these explicit versions:

November 2017 version of the Scrum Guide: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Daily Scrum News: Beyond the Three Questions

Today I’d like to highlight one of the major changes in the November 2017 version of the Scrum Guide: it has to do with the Daily Scrum – the famous 15-minute Development Team meeting, probably the most well-known element of Scrum, you know, the one with the three questions. Well, it’s not about the three questions anymore!

Continue reading “Daily Scrum News: Beyond the Three Questions”

Scrum is more than CSM – Scrum Gathering Dublin

Instead of Halloween, for me it was “Gather-ween” this year. Monday through Wednesday, 30.10. – 01.11.2017, I attended this year’s European Scrum Gathering, organized by the Scrum Alliance. After Munich in 2016, this year it was Dublin’s turn. The conference motto “Individuals and Interactions” created the umbrella for three intensive days with lots of different offers, ranging from classical talk sessions to “clinics” for coaches and trainers to new experiments like the Games Track or a Late Night Coaching Session. There were about 650 attendees, for about half of them it was their first gathering, resulting in a colorful mix of newbies, practitioners and seasoned experts from all over the world.

Emphasis on Leadship and Values

It was my fifth Gathering and probably the most intensive one. From my perspective, the dominating topic was “Agile Leadership”. In his key note, Michael Sahota used several live polls to ask the attendees if the implementation of Agile in their context remained below its potential (80%: YES!), and then asked for the reasons (“Incompatible culture, “Management doesn’t understand Agile”, …). This set the stage for much of the conference.

Several session adressed the topic “Agile for Managers” from different perspectives. Apparently seemingly soft factors like personal growth, values (what’s really important to me), and intents (what do I want to do today to put these values into reality), were of crucial importance. When somebody asked why Agile sounds more and more like a religion, Michael protested: “This is no fluffy bunny stuff. This is about the core of how to be successful in business!“

CSP Certifications will become much more difficult in 2018

For many participants, the CSP Area was of imporance. Here, the Scrum Alliance presented the evolution of the path to the Certified Scrum Professional (CSP). After the CSM or CSPO, which remain the entry level certificates, you can now take an advanced Certified Scrum Master Course (A-CSM) or the corresponding A-CSPO). After another year, you may now get certified as a Certified Scrum Professional ScrumMaster (CSP-SM) or Certified Scrum Professional Product Owner (CSP-PO).

This is the attempt of the Scrum Alliance to support the mostly role-oriented agile journey of their CSMs and CSPOs with an improved structure of accompanying courses and certificates. It is also a reaction to the critics that say that a 2-day course can only be an introduction and in no way makes one a “master”. This new program is more challenging than the previous CSP program. So, if you are currently preparing your CSP certification, hurry up and turn it in before 31.12.2017.

For details, please refer to  https://www.scrumalliance.org/certifications/certifications2017

Coaching Clinic and Trainers Clinic offer practical advice

In addition to the traditional Coaching Clinic, where everyone can talk to an experienced coach about their current challenges, this year, there was a new area called “Trainers Clinic”. Here CST (Certified Scrum Trainer) candidates could talk to members of the TAC (the Trainer Approval Committee) and to other  CSTs, to those with years of experience and to some of the 13 CSTs approved right before the gathering – very exciting for me. Some practical question concerning training methods or the trainer approval process could be cleared up right away. Hopefully, in the future, not only CSTs but also ordinary Scrum Masters get better support when they want to get Scrum concepts across to their teams.

Insightful conversations and personal exchange are essential

Even more valuable than the talks and clinics was the opportunity to get into contact with so many leaders of the Agile community. For example, during the ride to the Monday Mingle (an evening event), I got to sit next to some Mike. I soon found out that it was actually Mike Beedle, one of the 17 co-authors of the Agile Manifesto. It was really interesting what he had to say about this historical weekend in 2001. At the event location, Jeff Patton, whose book “User Story Mapping” I value a lot, joined us for a relaxed and humorous conversation. The next day, during a Large Scale Scrum LEGO workshop, I got to talk to Alexey Krivitsky, the Scrum trainer that originally created the idea to use LEGO to get Scrum concepts across. And of course, I was able to deepen my connections to German Scrum trainers and coaches – a very helpful and friendly community.

Why don’t you join in the next time?

The next Scrum Gathering takes place in April (16.-18.4.2018) in Minneapolis. The next European Gathering is in London in October (8.-10.10.2018). See you there …

Shu-Ha-Ri: Karate for ScrumMasters

Sometimes I hear new ScrumMasters ask how closely they should stick to the rules of the Scrum Guide. For example, should they facilitate the Daily Scrum very strictly, expecting everybody to answer the three questions, or should they let the team self-organize, exchanging whatever information the team members want to give.

And surprisingly, a litte bit of Karate knowledge is really useful in situations like this.

Karate, just like in many other martial arts, knows three levels of learning, that every student passes through on his journey from their first steps to true mastery.

The first level, called “Shu”, literally means something like “obey”. The student imitates others and follows the rules closely. The idea is that only those that know the rules, will be able to break then safely without losing the art.

The second level, named “Ha”, might be translated as “break” or “liberate”. In the Ha level, students learn to adapt the rules to the circumstances. They learn about the principles behind the rules and learn when the principle is better followed by breaking the rule than by obeying it. So they move beyond just following the rules.

The third level is called “Ri”, which means something like “leave” or “cut off”. At this level, students leave the established rules behind to develop their own way, guided by their impulses. A lot of experience and mastery of the rules is essential in order to apply the ideas behind the established theory freely and independently.

As a ScrumMaster, you can apply this directly to your team. Are they new to Scrum and still have trouble following the rules? Then they are at the Shu level. Help them by providing structure and assurance. Teach them the rules friendly, but firmly. Assure them that these rules have helped thousands of teams to become successful, and don’t be afraid to take on a strong facilitating role.

After a while, the team will know the rules and is ready to move on to the Ha state. Then it’s time to step back and let them find different ways to collaborate during the Daily Scrum. Make sure that they know the true purpose of the Daily Scrum, and encourage them to experiment with different ways to reach this purpose.

How do you know if your team is ready to move from Shu to Ha? Just watch them. If they are able to follow the rules, lighten your facilitative touch. Will they start breaking the rules in order to hide some dysfunction? Then they’re not ready, yet. Go back to teaching and be patient. Or will they start to discuss how to better follow the principles? Then your team has reached the next level.

So this is, how Karate can help you how to better support your team on its way to learning about Agile and Scrum. If you want to know more about the topic, there are great books to read, e.g. “Coaching Agile Teams” by Lyssa Adkins.

And – just in case you are about to complain that I didn’t mention when and how to move your team from Ha to Ri: this means that you have to reach Ri yourself, first. And then you won’t need this blogpost to tell you…. :-)

A Sprint Review is not a Signoff Meeting

Some bad ideas just seem to live forever, here is one of them: sign-off during Sprint Review. But let me start with a short, true story:

Last week I was invited to a Sprint Review Meeting to give some feedback and offer ideas for improvement. There were about twenty people in the room, some managers, some collegues from other teams, some stakeholders, and, of course, the Scrum Team themselves. Things started pretty smoothly, the ScrumMaster gave a short overview of the items planned for the Sprint, and then the Development Team presented  these items. I could see some happy faces among the stakeholders, but nobody asked them for feedback. Instead, the ScrumMaster asked the Product Owner if the item was done. The PO was somewhat hesitant, opened his laptop to check some notes and started to discuss the acceptance criteria with the team member that had demoed the item. Finally he decided that the item was not really officially done, but good enough to be waived through. A stakeholder protested, and the discussion continued. The meeting was derailing quickly. At the end of the timebox, everybody was exhausted and frustrated, only dreading the rest of the day with the retrospective and the planning for the next sprint still lying ahead.

This is NOT how it is supposed to be!

The team had done some really important things quite right like

  • actually having stakeholders outside the Scrum Team at the review
  • letting the development team demonstrate the new features
  • showing a real product during the review.

But they had been mistaken about one thing: the Sprint Review is NOT meant to be a signoff meeting. Of course, it should be made transparent, which items are done, and which are not done. But the Product Owner should bring this information to the Review, having clarified it with the team during the Sprint. This has two main advantages: first, the feedback loop is drastically shortened, enabling the team to fix an item considered not done when shown to the Product Owner for the first time. Second, during the review the Scrum Team can focus on the real purpose of the meeting: to obtain feedback on the product and to come up with ideas how to use the next sprints in a better way than previously planned.

For more information about the purpose and recommended content of the Sprint Review, just take the time to have a look at the Scrum Guide.