The Updated Scrum Guide
Since first being published in 2010, the Scrum Guide has always been a living document, and this update is there to address the common misinterpretations and misunderstandings.
Scrum has not changed at all, but the description of it has got better.
Scrum’s Simple Rules Remain
Scrum Artifacts and Commitments
There are still just three Artifacts in Scrum, the Product Backlog, the Sprint Backlog, and the Increment, with each representing work or value and is designed to maximize the transparency of key information.
These Artifacts has a new corresponding commitment:
• The commitment for the Product Backlog is the Product Goal
• For the Sprint Backlog, it is the Sprint Goal
• For the Increment, it is the Definition of Done
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team, their stakeholders and provide better focus on how to align teams on the goals and the steps needed to make them a reality.
The Sprint Goal
This is the single objective for the Sprint for the team to focus on what the purpose of the Sprint is:
- What do all these things add up to?
- What are we trying to accomplish?
It answers the most important question in Scrum, why?
The Sprint Goal is the Team’s commitment to what will be delivered by the Sprint Backlog. The Sprint Backlog is an intimate description of what that Goal is.
The Sprint Goal creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
Learning Today Leading Tomorrow!
All Courses for less than $10/month if paid annually
The Product Goal
This is new to the 2020 Scrum Guide.
The Product Goal is a step towards achieving the desired future state of the product and serves as a target for the Scrum Team to plan against.
The Product Goal describes the future state of the product and is in the Product Backlog.
The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product could be a service, a physical product, or something more abstract.
A product is a vehicle to deliver value with a clear boundary, known stakeholders, well-defined users, or customers.
The Definition of Done
This is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
Part of the value of the Definition of Done is that it gives the Scrum Team a clear marker on when things are done. It gives you one of the greatest deliverables in Scrum: The work not done. It tells Scrum Teams where to stop.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Team commits to reaching that Product Increment at the end of each Sprint. In each increment, every time something hits that Definition of Done it is their commitment to delivering quality and value in every Product Backlog Item they create.
The Scrum Team
A Scrum Team commits to deliver something of value. A Product Goal. Each Sprint Goal is their commitment to getting closer to that. If something does not meet the Definition of Done it can’t be released and should never be demonstrated at Sprint Review.
The Scrum Team commits to achieving its goals and supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.
The Scrum Team and its stakeholders are open about the work and the challenges.
Scrum Team members expect each other to be capable, independent people, and are respected as such by the people with whom they work.
The Scrum Team members have the courage to do the right thing, to work on tough problems.
It is the commitment of the Scrum Team to deliver value, to reach goals, to solve problems, and to support each other in doing so.
Elevating Scrum Master from A ‘Servant Leader’ To ‘Leader Who Serves’
The main purpose of the Scrum Master has been to significantly improve team performance, not just for the team, but is now expanded to helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
This would include the leadership aspects of a Scrum Master including, training, and coaching the organization in its Scrum adoption
Understanding this expanded role of the Scrum Master is key to understanding why the term ‘servant leader’ is replaced by ‘leader who serves’.
Effective Scrum Masters do more than just facilitate Scrum Events and service impediments. They are proactive and do what must be done to help the Scrum Team and organization achieve great results.
A Single Team Focused on One Product
This used to refer to two teams, the ‘development team’ (those who did the work), and the ‘Scrum Team’ (the development team plus the Scrum Master and the Product Owner.
There is now just one team, the Scrum Team, focused on the same objective, with different sets of accountabilities for the Product Owner, Scrum Master, and Developers.
From Self-Organizing to Self-Managing Scrum Teams
Development Teams were described as self-organizing, meaning they chose who performed the work and how. The emphasis now refers to a self-managing Scrum Team, choosing what to work on, who is going to do it, and how it will get done.
The team self-manages to deliver on the commitments and to meet the goals. they are accountable for achieving their goals. The team self-manages to deliver on the commitments and to meet the goals.
Self-managing brings clarity to the concept and stops using self-organization as an excuse to avoid meeting goals or commitments.
What’s No Longer in The Scrum Guide
To keep to the standard of a minimally viable framework, some things have been removed and are optional practices that can help lead to high-performing Scrum Teams.
The Three Questions Answered at The Daily Scrum:
The three questions were overly prescriptive and limiting. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work, and there are many ways to achieve that purpose.
“Parking Lot” After Daily Scrum
This referred to any conversations that need to take place beyond the event’s 15-minute timebox. The 2020 Scrum Guide lets the Scrum Team decide when these important conversations take place.
The Word ‘Roles’ When Describing the Scrum Master, Product Owner, and Developers
The word ‘roles’ was being misunderstood in some situations.
The new emphasis now is the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Scrum defines three specific accountabilities within the Scrum Team: The Developers, the Product Owner, and the Scrum Master.
A Sprint Review Led Only by The Product Owner
The Product Owner was the lead during the Sprint Review with the rest of the Scrum Team in a supporting role.
The Scrum Guide now has the entire Scrum Team, along with customers and stakeholders, at the centre of this event.
Prescriptive Language for The Sprint Retrospective
The overall description of this Scrum Event has been shortened to focus on process improvements, team happiness, and cohesion, giving individual Scrum Teams flexibility in how they approach the Sprint Retrospective.
Timebox For Backlog Refinement
The previous guide stated that no more than 10-percent of a team’s capacity should be spent on refining the Product Backlog. It is now the Scrum Teams’ decision on how much time is needed to refine and understand Product Backlog Items.
Changes To the Five Scrum Events
The Scrum Guide includes minor changes to each of the five Scrum events.
Previously the Guide listed two topics the Scrum Team should discuss at this event:
What can be delivered in the Increment in the upcoming Sprint How the work will be achieved.
These two topics yield important information and a shared understanding that helps the Team achieve their Sprint Goal.
However, a Scrum Team must also understand why.
So, a new topic for discussion has been added to Sprint Planning – Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates and discusses on defining a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
Scrum Teams who understand the intent of the Product Owner deliver better results and higher quality.
The Sprint: The Scrum Guide now explicitly states that only the Product Owner can abort a Sprint
The purpose of the Daily Scrum remains the same; to inspect progress toward the Sprint Goal and adapt and replan the Sprint Backlog as necessary.
What has changed in the Scrum Guide is the method. Gone are the three questions listed in previous guides, replaced with a less prescriptive description:
The Developers can select whatever structure and techniques they want, provided their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. Scrum Teams now have the flexibility to use the approach that best works for them. This creates focus and improves self-management.
The Sprint Review is the venue for customers, stakeholders, and the Scrum Team to discuss how they achieved the Sprint Goal, progress towards the Product Goal, and what problems have been overcome, and what remains in their way.
In Scrum, the work is accomplished by the team, with the Sprint Review as inclusive as the work itself. The Sprint Review is no longer lead by the Product Owner, but by the Scrum Team as a whole:
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next.
The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation.
The Sprint Retrospective should focus on two things: respect for people and continuous improvement.
Retrospectives are successful if the conversations are open, honest, and focus on improving processes and interactions. There are many ways to achieve this.
The new Scrum Guide encourages the Scrum Master and the whole Scrum Team to be flexible in finding creative ways to solve problems by first finding their root cause.
Sometimes these solutions are the removal of impediments. Others are potential process improvements identified by the Scrum Team.
The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
This is also a change from stating these improvements will be implemented next Sprint – although still a leading practice, it is not a must – the key here is to remain flexible.