2013 Scrum Guide –Value, Transparency, Planning and Team Work
The originators of Scrum, Ken Schwaber and Jeff Sutherland have released an updated version of the Scrum Guide.
Go here to get the latest version
Go here for their summary of the changes
http://www.scrumguides.org/s/Scrum-Guide-2013-Changes.pdf
Go here for a 17 min video of them discussing the changes.
http://scrumguides.squarespace.com/2013-scrum-guide-changes-video/
Here are my key points taken from the video, and the summary page, and a few comments about them.
Interesting points on the uptake of Scrum
- two years ago the US Congress passed a law that all Department of Defence IT Projects must be agile
http://scrum.jeffsutherland.com/2012/04/dod-goes-agile.html
- this year.. the US embedded the Agile Manifesto in its government regulations
- The US post office has mandated Scrum everywhere in IT
- The Gartner group says 'abandon waterfall.. get agile'
http://www.gartner.com/newsroom/id/2207915
-Jim Johnson at the Stannis group repots: In a survey of 50-100,000 projects where success is defined as on time, on budget with happy customers (in itself a waterfall benchmark) -
The success rate in waterfall projects is 14%
The success in agile is 42% (Jeff believes this is not great.. but a conservative figure)
- The Forster report: next year there will be 3 trillion dollars spent on software
Ken: "our way of trying to narrow the gap between software that is needed and the available provisioning capacity is
- higher productivity
- higher value
- higher quality"
The 6 key changes to the 2013 Scrum Guide
1. Re-emphasising Transparency
A new section on Artefact Transparency has been added.
The key point made was that Ken and Jeff wanted to make it clear that if things are not visible to everyone, bad decisions can be made.
All of the Scrum artefacts should be transparent, and easily understood by everyone who is looking at them in order to maximise value and minimise risk.
2. Sprint Planning – One Section and a Sprint Goal
The sprint planning meeting is no longer divided into two sections.
The concept of the Sprint Goal was in the 2011 scrum guide, but it wasn’t clear enough and not enforced enough.
In the current edition, you must come out of sprint planning with a sprint goal.
The sprint goal should provide focus to the team.
3. Product Backlog – being ‘Ready’
The term 'Grooming' has been replaced with the term 'Refinement' (due to cultural sensitivity).
The 'Ready' state is being emphasised (as has previously been done with the 'Done' state)
Items that are 'Ready' are defined clearly enough and with enough detail to be able to be added to a sprint.
BEFORE the sprint planning meeting, PBIs that may be added to the sprint should be refined until they are 'Ready'. This will accelerate the sprint planning meeting.
I think this is awesome. As a consultant, one of the issues I commonly find on Scrum teams is that the Sprint Planning meeting drags.
I always push back on Product Owners that if they want punchy Sprint Planning meetings, they should prioritise having a well groomed backlog with all of the BPIs likely to be included in the next sprint ready for estimation and inclusion.
4. Time Boxed Events
When you set the length of the sprint it does not change, but the meeting times specified are maximums.
(I don't see this as a big change).
5. Daily Scrum – a Planning Event
The new guide reinforces the importance of the Daily Scrum as a PLANNING event, not just a status event.
It provides a great focus on each team member contributing and delivering value.
Ken: 'It is about creating situations for the team to work together'
Every day the team should organise how they will work together to accomplish the sprint goal
The input to the meeting is how well the team is going.
The output from the meeting is a new or revised plan that optimises the teams efforts.
The three questions have been reformulated to emphasise the team over the individual.
a. What did I do yesterday that helped the Dev Team meet the Sprint Goal?
b. What will I do today to help the Dev Team meet the Sprint Goal?
c. Do I see any impediment that prevents me or the Dev Team from meeting the Sprint Goal ?
There is a greater focus on the sprint goal, rather than just on the status of what 'I' did.
Only tasks that contribute to the sprint goal are relevant.
A great example is given
- if a team member says 'I spent the day writing this great report' but the report does not contribute to the sprint goal
a. it should not have been included in the daily scrum (as it does not contribute to the sprint goal)
b. if they team member was busy, but did not contribute to the sprint goal, as far as the daily scrum is concerned... they did nothing
c. it could actually be considered an impediment as the team member is not focused on the sprint goal
6. Delivering Value
The concept of value is reinforced.
The product backlog should be prioritised by value.
At the end of the sprint review, one of the primary outputs should be a refined sprint backlog that will optimise the VALUE of the work the team is doing.
During the sprint review - the question is asked 'based on what was done in the sprint what are the next things that could be done to optimise value ?'
The point is to maximise the value that the team delivers.
I say: Bravo !
Great quote: "We've got goals, we've got value, we've got transparency, we've got more teamwork ..it's all good."
Other references:
http://scrum.jeffsutherland.com/2012/12/tipping-point-get-agile-or-get.html