The 2013 Scrum Guide changes: what you need to know

Big Thoughts

30 August 2013 • Written by Edwin Dando

After three weeks in the US with Scrum creators Ken Schwaber and Jeff Sutherland, Edwin Dando here outlines the key changes to the 2013 Scrum Guide

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


The Scrum Guide now explicitly states how critical it is that all the Scrum artefacts (Product Backlog, Sprint Backlog and Increment) are transparent. It includes specific responsibility for the Scrum Master to work with the Development Team and Product Owner to ensure all artefacts are transparent. Why?

Scrum relies on transparency (the three pillars of Scrum are transparency, inspection and adaption). Decisions to optimise value and control risk are made based on the perceived state of the artefacts. When the artefacts are transparent, these decisions have a sound basis. When the artefacts are not transparent, these decisions can be flawed, value may diminish and risk may increase.

How transparent are your artefacts?

Is your product backlog hidden away in a spreadsheet or a tool somewhere or is it displayed on a wall somewhere accessible and written in language that anyone (even the janitor) can understand? Do people have to actively hunt down your product backlog? And then when they do find it, is it limited to the size of a computer screen?

How transparent is your increment? Does your Product Owner know what is being inspected in the Sprint Review? Is your Definition of Done also transparent?


Sprint Planning has changed

There are two key changes to Sprint Planning.



Firstly, Sprint Planning is now one event. People were taking the split of the meeting too literally and spending four hours discussing ’what’ and then another four discussing ‘how’. However, sometimes you need to do the ‘how’ in order to understand the ‘what’. ‘What’ and ‘how’ are still addressed – you just don’t have to do it in two separate meetings.

Secondly, the Sprint Goal inclusion is now very explicit. The output of Sprint Planning is a Sprint Goal and an accompanying Sprint Backlog (which together are considered a forecast, not a commitment – a 2011 change).

So why the Sprint Goal?

The objective of a Sprint is to deliver value to the stakeholders. However, simply following a list of PBI’s and tasks does not necessarily result in creation of greatest value possible.

The Sprint Goal is a short statement of the value that the team intends to create during the Sprint. This becomes the focus of all work in the Sprint. It allows the Scrum Team to change the content/scope of the Sprint and still arrive at some business value. That is, it focuses the Development Team on the underlying reason for the Sprint, as opposed to just the items within it.

An example of Sprint Goals might be “Increase search accuracy by 20 percent” or “Make the application run on SQL Server in addition to Oracle”.

How could you better use Sprint Goals?


Definition of Ready

When a team introduces PBI’s that are not ready to be worked on or PBIU’s that contain ambiguity, waste occurs. Waiting time = waste. 


It is critical that the team understands what is being asked for in order to maximise value delivery. The Definition of Ready (DoR) is an explicit policy developed by the Scrum Team that specifies what ‘ready’ means for all PBI’s entering the Sprint. It helps ensure that the most valuable PBI’s are ready for consumption by the Development Team.

Jeff Sutherland ran some experiments using DoR and found one team in Germany got a doubling of velocity by simply ensuring their user stories were ‘ready’.

I have worked with a number of teams using DoR since Jeff introduced me to the term when we hosted him in NZ in 2010. They all now see it as a critical part of the framework, so I am wrapped to see it explicitly included now.

However, I do see potential issues with the application of the DoR. Those stuck in the predictive thinking mind-set could easily misinterpret this as an excuse to revert to bug up front analysis and design. Remember – the product backlog is a queue and queues highlight waste in a system. The most efficient possible requirements storage system is a minimal one that contains items that prompt a face-to-face conversation in front of a whiteboard.

How could you use the Definition of Ready in your work?


Time boxes relaxed

This is possibly the most controversial one. Here’s what has changed:

a)     The wording has changed to highlight time boxes are a maximum

b)     The time limits have been relaxed for the Sprint Planning, Sprint Review and Sprint Retrospective meetings. The wording is now “If the Sprint is less than one month, the meetings are usually shorter”. This means a Sprint Planning meeting could be eight hours for a one-week Sprint, if you so desired. 



The event length is somewhat arbitrary compared to value of event. Scrum is about value: plan to do the most valuable work, adjust the plan daily as you deliver, inspect the work to adapt our next optimal move, then inspect and adapt our process-seeking improvements. The responsibility for value creation ultimately lies with the Development Team. We want them to become a self-organising unit. Dictating their meeting length can impede this. Ideally, we want them to manage this themselves (however a maximum is maintained as a container).

For those uncomfortable with this change, I suggest this. You can ask your team what time box they would like to apply prior to the meeting and, as the Scrum Master, still provide a service to the Development Team by making them aware of this time box as they go.

Note, the primary container for managing complexity – the Sprint – is firmly time-boxed. The Daily Scrum is also still limited to 15 minutes.


Major 5: Daily Scrum

The wording for the purpose of the Daily Scrum has changed to place the emphasis:

a)     that it is a planning meeting focusing on the Sprint Goal, not a status meeting

b)     on the Team, not the individual


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. 


Search the Assurity website (Hit ESC to cancel)