Ready to get a handle on the new Scrum Guide? I share my thoughts on the nine biggest changes in the new Scrum Guide and their possible impact on your team.
| What Changed in the New Scrum Guide | Why We Think This Change Was Made | Our Take | Impact on Your Scrum Team |
|---|---|---|---|
| “Servant Leader” Replaced by “true leaders who serve” | More emphasis on “leader” aspects of the role, rather than “servant” aspects. | This seems like an unnecessary change for those practicing Servant Leadership as intended – which is based on the concept that knowledge workers do their best work when their leader serves their needs rather than dictates what they should do. | If your SM already prioritizes team development and effectiveness, then there likely won’t be much change. If your SM was more of an administrator, it’s time to reevaluate. |
| “Self-Organized” Teams Replaced by “Self-Managed” Teams | Teams needed more direction and autonomy. Self-organizing includes the how and who of a task, and self-managing includes both of those as well as the what – the goal that the team wants to achieve. | This makes sense and compliments the introduction of the Product Goal. The Product Goal is the what that a self-managed team self-organizes toward. Now the team has full transparency on the who, the how, and the what. | Teams are now responsible for the what (the goal the team wants to achieve). Use the Product Goal and Sprint Goal to decide what to self-organize toward. The Sprint Goal and Product Goal are the guardrails for what the team should work on. |
| “Development Team” Changed to “Developers” | To avoid confusion about a “team within a team,” there is no more “Development Team,” just “Developers.” | This is a much-needed change that cuts down on the confusion of having a team within a team. Some teams were even confused about if the Development team should self-organize or not. Other teams thought the Development Team was the Scrum Team. | We don’t think this will have a huge impact. There is simply no more Development Team and the focus is on one cohesive Scrum Team that collaborates to get the job done. |
| Three formal “commitments” have been introduced: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment. | The Guide makes it clear: The commitments were introduced to enhance transparency (by providing more information) and focus (by providing a way progress can be measured). | This is a welcome change that clarifies the connection between the goals in mind and the work that is performed. It increases transparency and gives the team a clear way to measure value. | Your Scrum team now has a good reason to maintain the artifacts properly and a solid way to track your progress. The Product Backlog is now prioritized to suit the Product Goal; the Increment must be verified against the Definition of Done; and the Sprint Backlog is organized toward the Sprint Goal. |
| Introduction of a “Product Goal” | Previously known as the “vision.” Not given much importance in SG 2017 and needed to be expanded further. Now known as the Product Goal commitment, which is tied to the Product Backlog artifact. This makes Product Goal more visible and reinforces its importance. | This is a much-needed change. It makes it easier to understand how long-term objectives are handled in Scrum and how each Increment of delivery should contribute to the Product Goal commitment. Secondly, the update makes it clear that “The team must fulfill (or abandon) one objective before taking on the next.” This is a solid addition because the team can now hyper-focus on delivering value. | If your team doesn’t already define a long-term objective for your product, this will change that. Introduce the Product Goal commitment for your Product as soon as you can. Remember, the Guide defines Product as “a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, a physical product, or something more abstract.” |
| “Roles” Changed to “Accountabilities” | “Roles” were being confused with job titles. | Without formal roles, using the word “Accountabilities” to describe a certain set of duties may create more confusion. So, we think this is an unnecessary change. Roles and titles should never be confused; both are important, and it’s leadership’s responsibility to make the distinction clear. | We recommend that you continue to designate roles to individual team members on your Scrum Team (Scrum Master, Product Owner, and Developers). Not doing so could cause confusion around which accountabilities belong to whom, which leads to chaos and inefficiency. |
| Three standard Daily Scrum Questions Removed | The questions were removed because they were being used mechanically at Daily Scrum Meetings, which doesn’t reflect the essence of Scrum. | We have mixed feelings on this change. Yes, many teams were using them mechanically, but at the same time, they provided direction for team members to plan their day. Without this guidance in the new Scrum Guide, the Scrum Masters now have more responsibility to see that the spirit of the Daily Scrum is maintained (which is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary). | Scrum Masters need to be extremely careful in implementing this change. Just because the questions have been removed doesn’t mean that your Daily Scrum shouldn’t have any structure. Work with your team to introduce a structure that works for you. |
| New “Why” topic added to Sprint Planning meeting | The Sprint Planning meeting used to only cover the what and how of the Sprint. Now, it also includes the why of the Sprint, asking the team to identify why this Sprint is valuable? | This is a welcome change. The why adds more clarity to the Sprint Goal, which helps the team decide the what and how more easily. It complements the shift from a self-organizing to a self-managing team. | Many teams already identify the why in their Sprint Planning, but now it’s given even more importance. To start adding the why, your PO should explain to the team how the current Sprint could increase the value and utility of the product. Use that as a jumping off point. |
| Multiple Increments can be delivered within a Sprint | This change will encourage the team to move toward continuous integration and continuous deployment (CI/CD) The Guide now says, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” | We like this change. It helps the team focus on smaller increments of value delivery. | This change should help your team improve continuous integration and smaller deployment. Also, it forces teams to take test automation into account. |
Want more insight on Living Agile? Subscribe to our newsletter.
Still have questions about the new Scrum Guide? Read it in full, or drop your question in the comments below!