The 2013 Scrum Guide changes

During my three weeks recently in the US I caught up with Scrum creators Ken Schwaber and Jeff Sutherland. Following this I thought I would pull together a post about 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 aretransparency, 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 proportionally shorter 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.


  1. Great article and thanks for summarising the SCRUM changes so well. I am wondering if you could elaborate on the DoR concept as I’m not familiar with it and still unsure whether this is like an Acceptance Criteria being set against each individual PBI or rather a set of gating requirements that each PBI must meet before being accepted into the Sprint?

    Thank you.

  2. I guess the way to think about it is “what is needed to have this PBI in a state where the team can start work on it” Acceptance criteria relates to each specific PBI, whereas the DoR is a guide for all PBIs and helps in the art of refining them for consumption by the team. For example, this might include ensuring each item is clearly understood by the Development Team, that the item has clear business value and is within a certain size threshold so that pulling it into the sprint won’t introduce undue risk. It might also include things like:
    – we know how to deploy this item
    – any people required to sign this off have been prepped in advanced
    – we understand the UX input

    This article is a reasonably comprehensive guide:

  3. i wasn’t aware of these updates but having just implemented scrum at work for the first time and strangely enough, some of these changes were what we decide to implement as a part of inspect and adapt anyway.

    DoR is very interesting though. definitely need to look into that more.

    • Edwin Dando says:

      I am glad this helps. Like most things in Scrum, it is very common sense. Here at Assurity we run a bi-annual survey on software project failure in New Zealand. We contracts failure here against worldwide failure trends to figure out what is different about NZ. One interesting outcome is that the number reason projects fail is due to the people doing the work not clearly understanding what is wanted of them (i.e. scope). What better way to address this than by having the Team develop the Product Backlog and define a clear DoR to ensure they only pull in work they understand?

      I think one of the other important aspects people forget is the Sprint Goal. It is the entire point of the Sprint and gives an overarching objective that is deeply important, yet often missed.

      Thanks for the feedback. I appreciate the interaction 🙂

  4. Good post! I usually try to get a grip on the size of the bacolkg too, but I still want to do poker sessions at the start of a sprint. In my opinion these sessions help to get a shared vision on what it is that we are making. We tried just elaborating on the stories, but I experienced that with the pokering more information was revealed. Risks and better work breakdowns emerge from the discussions we have while pokering. Note that we usually skip the lower story points, since these most of the time turned out to be clear enough.

  5. Wham bam thank you, ma’am, my qusiteons are answered!

  6. Im going to be completely Doh!
    What is a Scrum Jedi?

    Do we think Sprint Goals are a bit of the old command and control creeping back in?

    • Edwin Dando says:

      Hey Tony,

      thanks for the comment. First off, there is no doh – all questions are good 🙂 The Scrum Jedi thing is a bit of a joke. As a Scrum Master you often have a lot accountability but little ability to control. A lot of what you achieve is through influence and people often comment that good Scrum Masters seem to use Jedi mind tricks to alter perspectives.

      Re Sprint Goals – I think there is potential for them to be used as a way to try to control the team, but the real purpose of them is a collaborative agreement between all of the Scrum Team (i.e. PO, SM and Dev Team) re what we are trying to actually achieve in the sprint. A lot of teams I have helped tend to loose sight of the goal as their focus is buried on Product Backlog Items (usually user stories) and tasks. Sometimes I ask them “if we completed everything on the Sprint Backlog (i.e. the PBI’s/tasks), would we actually achieve the Sprint Goal?”. Often the answer is “no.”

      The Sprint Goal trumps the Sprint Backlog. The objective is to deliver the Goal, not to just deliver the PBI’s and tasks you selected during Sprint Planning. After all, we know software resides in the Complex domain and has unknown unknowns – i.e. it is not predictable. Often once we start solving the problem in code we find things arent what we thought. We often find better ways of doing it, or that there are problems with our original approach. Without an opportunity to inspect and adapt, value is lost.

      Most Scrum teams struggle to move beyond a “predictability mindset” into true inspect and adapt thinking. They believe they can select all the work they are going to do for the Sprint during Sprint Planning, break it out (into a Sprint Backlog) and then deliver it during the Sprint. But isn’t that just mini waterfall? We know that no plans survives first contact with the enemy, ywt fall straight into the same trap, but this time do it in Scrum. NO!!!!

      Contrary to what a lot of people believe about Scrum, the Sprint Backlog is NOT “locked” or “fixed”. Doing this completely fails the entire point of agile – to be nimble enough to quickly and easily adapt to changing needs & challenges in order to deliver the maximum value possible. The Sprint Goal is an overarching objective that trumps everything. The Sprint Backlog is simply a mini-plan that reflects our current thinking of how we might achieve the Sprint Goal. Every day at the Daily Scrum the team inspect progress to understand their current position, and then adapt the Sprint Backlog (the plan) based around what they feel is the most valuable thing they can do in the next 24 hours to move towards completing the Sprint Goal. That is, the entire objective of the Daily Scrum is to come up with a plan for the day for how the team are going to progress forward towards the Sprint Goal.

      Make sense?

%d bloggers like this: