The 2013 Scrum Guide changes: what you need to know

New Thinking 30 August 2013 Edwin Dando

First, why is the Scrum Guide so important?

In 2008, our Scrum was in a bit of a mess. The prevailing Scrum training model was not working. Once a trainer was approved, they could then teach whatever material they wanted, with no checks and balances in place to ensure it was correct and consistent. As a result, there was a proliferation of inaccurate interpretations of Scrum.

People starting labelling any vague attempt at iterative, incremental delivery as ‘Scrum’. Some continued to use waterfall, but held a 15-minute stand-up meeting every morning and called this ‘Scrum’. Others did ‘Sprints’ of development followed by ‘Sprints’ of testing and called this ‘Scrum’. Those who knew better cried “That’s not Scrum”… but there was no reference point.

People starting using Scrum badly and there were some notable project failures. Scrum started fragmenting.

Ken Schwaber and Jeff Sutherland realised something needed to be done. The first step was to define Scrum. They codified the definition of Scrum in the 2009 Scrum Guide and provided the document for free. Since then, the framework has been adapted to meet the needs of the market and, in true Scrum style, it has become lighter each release. For example, the 2011 release did away with the need for burn-down charts. Instead, it said the team development team needed to update their progress every day in a transparent way. Whatever means they use to achieve this is a decision between the Development Team and the Product Owner.

Ken then took a bold second step. He established an improved business model at by centralising the training material. All trainers teach the same consistent material all the time. In addition, they are required to attend a face-to-face meeting annually to keep in touch with each other. All trainers teach the most up-to-date version of Scrum all the time and, as the changes to the Scrum Guide occur, the material changes with it.

The 2013 changes have now been released. I have been running a nationwide series of free events to update the NZ community. If you didn’t get a chance to attend one of these, read on...

The major changes, as I interpret the 2013 Scrum Guide, are as follows:

  1. Artefact Transparency strengthened
  2. Sprint Planning
  3. Definition of Ready
  4. Time boxes relaxed for most meetings
  5. Daily Scrum purpose clarified


Major 1: Artefact Transparency strengthened

Many teams treat the Daily Scrum as a status meeting. I often see Scrum Masters standing in front of the team board, with Development Team members addressing them as if the Scrum Master was in charge:  “I did X yesterday, I will do Y today. No impediments”. This completely misses the point.

The point of the Daily Scrum is for the Development Team to update their plan (the Sprint Backlog) towards completing the Sprint Goal. It is about the next optimal move, not about reporting to Mummy or Daddy.

To increase the focus on team over individuals, the three questions (which have only ever been a guide) have been reformulated:

  • What did I do yesterday that helped the Team meet the Sprint Goal?
  • What will I do today to help the Team meet the Sprint Goal?
  • Do I see any impediment that prevents the Team from meeting the Sprint Goal?

For example, imagine I am a developer on the team and I get dragged off by my manager to deal with the most current ‘critical issue’.  The old approach would be “Yesterday I didn’t get this done because… Today I am going to… I have an impediment”.

Now it is, “Yesterday I didn’t do anything to progress the team because…”. We are expecting the Development Team to react something like this: “What??? Why not? We have an impediment!”

Remember, high-performing teams have an identity of their own, greater than the identity of the individuals (think the All Blacks). It’s about the Team and, if there is an impediment, then it is the team’s impediment, not the individuals alone.

I hope you find this post valuable as a brief summary of the major changes. There are changes I consider more minor that I haven’t included here for the sake of brevity. However, please watch this video and read the 2013 Scrum Guide for the full picture.