A brief overview of changes to the Scrum Guide scrumguides.org
Added a section on Scrum Values: When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.
Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.
These values sound easy? Well, there are many misunderstandings and common problems when applying these values. Here are some examples.
|Commitment||Personally commit to achieving the goals of the Scrum Team.||Committing to something that you don’t understand because you are told to by your boss.|
|Focus||Everyone focuses on the work of the Sprint and the goals of the Sprint Team||Focusing on keeping the customer happy|
|Openness||The Scrum Team and its stakeholders agree to be open about all of the challenges with performing the work||Telling everyone it’s going to be done whenever it’s done|
|Respect||Scrum Team members respect each other to be capable, independent people||Thinking you are helping the team by being a hero|
|Courage||Scrum Team members have the courage to do the right thing and work on tough problems. The other values don’t work without it.||Even after the decision has been made continuing to push back|
Misunderstandings section from https://blog.scrum.org/updates-scrum-guide-5-scrum-values-take-center-stage/
Ken and Jeff talk about Scrum Values
- The importance of the Daily Scrum as a planning event is reinforced. Too often it is seen as a status event. “Every day, the Development Team should understand how it intends to work together as a self-organizing team”.
- What did I do yesterday “that helped the Development Team meet the Sprint Goal?”
- What will I do today “to help the Development Team meet the Sprint Goal?”
- “Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?”
- Backlog Grooming now backlog refinement
- Sprint planning is now one event. “Two topics are addressed: What can be done this Sprint and How will the chosen work be done”.
- Added “Artifact Transparency” (Product & Sprint Backlogs, Increment) – Decisions to optimize value and control risk are made based on the perceived state of the artefacts
Ken and Jeff talk about the changes between 2011 and 2013
- Added to the Daily Scrum “for the Development Team to synchronize activities and create a plan for the next 24 hours. The Development Team or team members often meet immediately after the Daily Scrum to re-plan the rest of the Sprint’s work. Every day, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work together as a self-organizing team to accomplish the goal and create the anticipated Increment in the remainder of the Sprint”.
- Removed Commit – “Commit to“doing” a Product Backlog item in a Sprint”. now “forecast the functionality that will be developed during the Sprint“
- Pigs and Chickens … the lore of Scrum (now removed)
- Release Planning and Release Burndown (now removed)
- The Backlog is Ordered instead of prioritized: “The Product Backlog is often ordered by value, risk, priority, and necessity”.
A note from our sponsor Jeff Sutherland
Become more open, visible and transparent to get the best ideas from everyone – everybody has to have a voice – only then can you steer things into the right direction, only then can you actually have an accurate forecast for delivery. We wanted to overcome the tremendous problems we’ve had with traditional project development where you never know when you’re going to deliver and when the date comes, you’re always late and often you don’t know how late it is! We need to overcome what Microsoft had in the early 90s with “I guess it’s going to be done whenever it’s done! – and we can’t tell you!”.
So only by making visible, systematically, real things working, constantly can you see steady progress towards the ultimate delivery of any piece of work.
Paraphrasing Jeff Sutherland, 2016 https://youtu.be/0hRZffDD1ec?t=13m2s
Oh and if you can create the right environment – it’s fun!