2020 Scrum Guide Explication des changements et des mises à jour
TABLE DES MATIÈRES :
Why We Updated The Scrum Guide
- Less Prescriptive Language
- A Clearer, More Universal Scrum Guide
- The Scrum Artifacts And Their Corresponding Commitments
- Scrum Master: From ‘Servant Leader’ To ‘A Leader Who Serves’
- Self-Managing over Self-Organizing
- Three Sprint Planning Topics
What’s No Longer In The Scrum Guide
- The Three Questions Answered At The Daily Scrum
- ‘Parking Lot’ After Daily Scrum
- The Word ‘Roles’ When Describing The Scrum Master, Product Owner, and Developers
- A Sprint Review Led Only By The Product Owner
- No Team-Within-A-Team
- Overly Prescriptive Language For The Sprint Retrospective
- Timebox For Backlog Refinement
2020 Scrum Guide Update: Scrum Artifacts And Commitments
2020 Scrum Guide Update: Elevating Scrum Master From A ‘Servant Leader’ To ‘Leaders Who Serves’
2020 Scrum Guide Update: From Self-Organizing To Self-Managing Scrum Teams
2020 Scrum Guide Update: One Scrum Team Focused On One Product
You can also learn more about the changes by watching the official 2020 Scrum Guide Launch event.
This latest iteration is cleaner, clearer, and more universal. The updates in the 2020 Scrum Guide are intended to drive the culture, focus, and alignment needed to innovate, create, and succeed.
Each day tens of millions of people, the world over, gather for their 15-minute Daily Scrum. A fact that is humbling to think about. We want to thank everyone, and there were many of you, who helped provide the insights, data, and real-world experiences that helped inform the 2020 Scrum Guide updates.
Why We Updated The Scrum Guide
Since first being published in 2010, the Scrum Guide has always been a living document. We use empiricism to periodically Scrum the Scrum Guide. As the guide itself states:
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
In a very real way, Scrum hasn’t changed at all, our description of it simply gets better as we get feedback on how people are using it. Iterating to a better outcome.
The 2020 Scrum Guide addresses the common misinterpretations and misunderstandings we and many others have observed as the use of the framework continues to grow.
2020 Scrum Guide: Overview of Changes
Below you’ll find sections explaining the ‘what’ and ‘why’ behind specific changes and updates in the 2020 Scrum Guide. But let’s start with this high-level overview of what you’ll find in the guide:
Less Prescriptive Language
At just 13 pages, the updated 2020 Scrum Guide is even less prescriptive than before while maintaining the standard of a minimally viable framework. The purpose here is to empower Scrum Teams and organizations to use the guide as it was intended; a rule book and not a playbook. This less prescriptive approach leads to more innovation and adaptations in how Scrum is implemented while keeping true to the framework.
A Clearer, More Universal Scrum Guide
Scrum is easiest when Scrum Teams and organizations see how the framework works for them, no matter their industry, domain, product, or function. This is why we’ve made the updated 2020 Scrum Guide more accessible and understandable for everyone, far beyond the technology business.
The Scrum Artifacts And Their Corresponding Commitments
Each of the three Artifacts now has a corresponding ‘commitment’. They exist to bring transparency and focus against which progress can be measured. The commitment for the Product Backlog is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.
The 2020 Scrum Guide introduces the concept of a Product Goal to provide a long-term focus for the Scrum Team. Each Sprint should bring the product closer to the overall Product Goal. Both the Sprint Goal and Definition of Done were in previous Scrum Guides. Now they have a clearer home and purpose.
Scrum Master: From ‘Servant Leader’ To ‘A Leader Who Serves’
This change will undoubtedly catch many by surprise. But don’t be fooled, the reordering of these words better captures the purpose and accountabilities the Scrum Master has always had.
A Unified Team Focused On One Product
Earlier Scrum Guides referred to two teams, the ‘development team’ meaning those who did the work and the ‘Scrum Team’ which included the development team as well as the Scrum Master and the Product Owner. This concept of a separate team within a team has sometimes led to an “us and them” relationship between the Product Owner and Development Team. 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.
Self-Managing over Self-Organizing
Previous Scrum Guides referred to Development Teams as self-organizing, meaning they chose who performed the work and how. With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, which chooses what to work on, who is going to do it, and how it will get done.
Three Sprint Planning Topics
In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide introduces a new topic, “Why”, referring to the Sprint Goal.
What’s No Longer In The Scrum Guide
In order to keep to the standard of a minimally viable framework, some things have been removed from the 2020 Scrum Guide. This, however, does not mean they have no place in Scrum or should not be used. Like Yesterday’s Weather and other Modèles Scrum not explicitly included in the Scrum Guide, they are optional practices that can help lead to high-performing Scrum Teams.
Here are the major concepts no longer included in the 2020 Scrum Guide and why:
The Three Questions Answered At The Daily Scrum:
You likely know these by heart; what you did yesterday to help the Development Team meet the Sprint Goal, what you’ll do today to help the Development Team meet the Sprint Goal, and do you see any impediments that prevent me or the Development Team from meeting the Sprint Goal? While effective, these three questions were overly prescriptive and limiting. As the 2020 Scrum Guide states:
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.
There are many ways to achieve that purpose.
‘Parking Lot’ After Daily Scrum
Sometimes the Daily Scrum identifies conversations that need to take place beyond the event’s 15-minute timebox. The prior guide stated these conversations, often called a ‘parking lot’ take place immediately after the Daily Scrum. 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. Scrum has never been about creating a taxonomy of titles. Roles were never intended to be a title. What matters is clearly defining who is accountable for what. Therefore the 2020 Scrum Guide includes this passage:
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.
This change puts the emphasis where it belongs, on specific accountabilities. You can still refer to them as ‘roles’ if you like. We are. But we too will emphasize these are roles with defined accountabilities.
A Sprint Review Led Only By The Product Owner
The prior guide gave the Product Owner the lead during the Sprint Review. The rest of the Scrum Team acted in a more supporting role. The 2020 Scrum Guide now has the entire Scrum Team, along with customers and stakeholders, at the center of this Event.
No Team-Within-A-Team
As stated above, the concept of a ‘Development Team’ inside the Scrum Team has been resolved.
Overly Prescriptive Language For The Sprint Retrospective
The overall description of this Scrum Event has been shortened to focus on what’s really important - process improvements and team happiness and cohesion. This gives individual Scrum Teams more flexibility in how they approach the Sprint Retrospective.
Timebox For Backlog Refinement
The prior guide stated that ‘usually no more than 10-percent of a team’s capacity’ should be spent on refining the Product Backlog. Removing the number empowers Scrum Teams to decide how much time is needed to refine and understand Product Backlog Items.
Now, let’s examine the major updates and changes found in the 2020 Scrum Guide in detail.
2020 Scrum Guide Update: Scrum Artifacts And Commitments
Arguably, the biggest change in the 2020 Scrum Guide can be found in the section on the Scrum Artifacts. There are still just three Artifacts in Scrum, the Product Backlog, the Sprint Backlog, and the Increment. Each represents work or value and is designed to maximize the transparency of key information.
Now each of 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
As stated in the 2020 Scrum Guide:
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
Commitment is, of course, one of the Scrum Values. The decision to use the word here, in concert with each of the Artifacts, is a deliberate one.
To learn more about these new commitments and how they drive focus, alignment, and value delivery read Scrum Guide 2020 insights by Scrum Inc.‘s CEO, JJ Sutherland.
Why This Update Was Made: It started with feedback from trainers and our own observations. Both showed there needed to be more of a focus on goals in the Scrum Guide. Specifically, how to align teams on the goals and the concrete steps needed to make them a reality.
Additionally, we’ve long known that teams that are focused on clear and specific goals do a much better job.
The Sprint Goal is not new to the Scrum Guide. However, this iteration gives the Sprint Goal a home and a more clearly defined purpose. Here’s how the Sprint Goal is defined in the 2020 Scrum Guide:
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Product Goal is new to the 2020 Scrum Guide. Added because we wanted to introduce a higher level of focus and alignment. The Product Goal is a concrete step towards achieving the desired future state of the product. Here’s how the 2020 Scrum Guide describes it:
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
The final new commitment is the Definition of Done. Like the Sprint Goal, it is not new to the Scrum Guide. Rather we have given the Definition of Done a home and a more clearly defined purpose. But there is a slight change in the term’s meaning in this context. Here is how the 2020 Scrum Guide describes it:
The Definition of Done 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.
2020 Scrum Guide Update: Elevating Scrum Master From A ‘Servant Leader’ To ‘Leaders Who Serves’
Another important change to note deals with the description and accountabilities of the Scrum Master.
From the beginning, the primary purpose of the Scrum Master has been to significantly improve team performance. That is not just a team-centered activity. Which is why the Scrum Master section in the 2020 Scrum Guides opens with this paragraph:
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The 2020 Scrum Guide advances this broader view of the Scrum Master’s role by spelling out some of the ways the Scrum Master serves the organization. This includes:
Leading, training, and coaching the organization in its Scrum adoption
Understanding this expanded role of the Scrum Master is key to understanding why we replaced ‘servant leader’ with the term ‘leader who serves’.
By going from 'servant leader' to 'leaders who serve', we’ve emphasized the leadership aspects of a Scrum Master. We have no intention of creating a hierarchy inside the Scrum Team. Nor are we saying the Scrum Master is now a manager.
What we are saying is that effective Scrum Masters do more than just facilitate Scrum Events and surface impediments. They are active, not passive. Great Scrum Masters do what must be done to help the Scrum Team and organization achieve great results.
Why This Update Was Made: It was time to clarify a misunderstanding. One that led many organizations to question why a Scrum Master was needed at all.
In 1986, the Harvard Business Review published Le nouveau jeu du développement de nouveaux produits par Hirotaka Takeuchi et Ikujiro Nonaka. This paper is a major reason they’re often referred to as the grandfathers of Scrum.
In this seminal work, Takeuchi and Nonaka describe how a facilitative team leader manages up and down. The organization and the team. This is how they manage the process. This was effectively the prototype of a Scrum Master. Someone who is getting management aligned with helping and supporting the Scrum Teams to do good work.
Some have misinterpreted the term servant leader in a way that has led us away from real leadership. So we changed the term to ‘leaders who serve’.
2020 Scrum Guide Update: From Self-Organizing To Self-Managing Scrum Teams
This is a subtle but important change that further empowers Scrum Teams while simultaneously making clear they are accountable for achieving their goals.
The previous Scrum Guide stated, “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”
The 2020 Scrum Guide now says this of Scrum Teams:
They are also self-managing, meaning they internally decide who does what, when, and how.
The team self-manages to deliver on the commitments and to meet the goals.
Why This Update Was Made: Scrum terms and concepts can be, in effect, weaponized in the workplace. Sometimes by management. Sometimes by the Scrum Team itself.
There are many Agile developers who view self-organizing as meaning they can do whatever they want. That’s a misconception that needed to be addressed. Self-organization occurs when an intelligent system finds the best way in an environment to achieve a goal.
So the 2020 Scrum Guide now uses the term self-managing to bring clarity to the concept and stop the weaponizing of self-organization as an excuse to avoid meeting goals or commitments.
You can learn more about why this and other changes were made in Dr. Jeff Sutherland‘s post about cells and teams as it relates to the new Scrum guide.
2020 Scrum Guide Update: One Scrum Team Focused On One Product
As we stated above, earlier Scrum Guides referred to two teams, the ‘development team’ meaning those who did the work, and the ‘Scrum Team’ which included the development team as well as the Scrum Master and the Product Owner.
This concept of a separate team within a team has sometimes led to an "us and them” relationship between the Product Owner and Development Team. 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.
Why This Update Was Made: We’ve pretty much covered it. However, there is one additional reason worth noting; making Scrum more accessible and understandable.
Scrum is easiest when Scrum Teams and organizations see how the framework works for them, no matter their industry, domain, product, or function. The team within a team concept could be confusing to many who were starting to implement the framework.
2020 Scrum Guide Update: Changes To The Five Scrum Events
The 2020 Scrum Guide includes at least minor changes to each of the five Scrum Events. So we’ll go through each one individually.
Sprint Planning: The previous Scrum Guide listed two topics the Scrum Team should discuss in this Event. What can be delivered in the Increment in the upcoming Sprint, and how the work will be achieved. Discussions of these two topics yield important information and a shared understanding that helps the Scrum Team achieve their Sprint Goal. And though reworded for clarity, they remain in the 2020 Scrum Guide. However, a Scrum Team doesn’t get the full picture by just understanding what and how. They must also understand why. So a new topic for discussion has been added to Sprint Planning. Here’s how the 2020 Scrum Guide describes it:
Topic One: 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 to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
Discussion of the why gives the Scrum Team the context that may otherwise have been lacking. We’ve found that Scrum Teams who understand the intent of the Product Owner deliver better results and higher quality.
The Sprint: The 2020 Scrum Guide now explicitly states that only the Product Owner can abort a Sprint. This really represents more of a clarification than a change since it has long been an established practice.
Daily Scrum: 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 2020 Scrum Guide is the method. Gone are the three questions listed in previous guides, replaced with this less prescriptive description:
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Indeed, there are many ways to achieve the purpose of the Daily Scum.
For example, a Scrum Coach in Europe began holding Daily Scrums where just one question was asked, why isn’t the story at the top of the Backlog done? That focus lead to an increase in performance of 500-percent.
We wanted to give all Scrum Teams the flexibility to use the approach that best works for them.
Sprint Review: In Scrum, the work is accomplished by the team. We wanted the Sprint Review to be as inclusive as the work itself. In the 2020 Scrum Guide 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 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.
Sprint Retrospective: Every Sprint Retrospective is really about just 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.
So we’ve removed the overly prescriptive language to encourage the Scrum Master and the whole Scrum Team to be flexible in finding creative ways to solve problems by first find their root cause. Sometimes these solutions are the removal of impediments. Others are potential process improvements identified by the Scrum Team. As the 2020 Scrum Guide states:
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 previous guides which stated these improvements will be implemented next Sprint. And while we believe this is still a leading practice, it is not a must. So we erred on the side of flexibility.
Closing Thoughts
We spend enormous amounts of our lives going to work. And for a lot of people, work sucks. In the creation of Scrum, our vision has always been to make work fast, easy, and fun. If it’s not fun, you’re doing it wrong.
With this latest iteration of the Scrum Guide, we’ve tried to clarify terms that have been misinterpreted. Simplify where it was too complicated. And make the framework more accessible so that any team in any organization, whether they are a sales team or an H.R. team, one that does marketing or finance, development or strategy, can pick up the Scrum Guide and begin.
That has always been the point. Scrum is open source for a reason. We want its use to spread. We want to help empower people to solve complex problems, to achieve big things.
We look forward to seeing what the Scrum community achieves next. And we’re proud of what we have already accomplished together.