Welcome to the Home of Scrum! ™

On November 18, 2020, Ken Schwaber and Jeff Sutherland released an updated version of the Scrum Guide. In this blog post, I will share what you need to know about the 2020 Scrum Guide. I will start with the most important things you need to know, and then I’ll get into a little more nuance for the Scrum nerds. First of all, Scrum is still Scrum. The Scrum Guide is not updated frequently (the last update was 2017). And when it is updated, Scrum does not fundamentally change. The Scrum Guide is updated in order to bring more clarity and to address common misunderstandings. What is important about Scrum is that it is a framework, and Scrum Teams need to define their process, practices, and tools within the framework. It is not meant to become a methodology, a body of knowledge, or a handbook. If you’ve taken a Professional Scrum course with me or read my book, you know my thoughts on best practices. The most significant change in the 2020 Scrum Guide is the introduction of the Product Goal. I see this as the most significant change because it is the addition of something new (which doesn’t happen often). This is the only new thing introduced in the 2020 Scrum Guide. The Product Goal is part of the Product Backlog. It is a commitment that helps enable focus and greater transparency. You can think of the Product Goal and Product Backlog relationship as being similar to the relationship between the Sprint Goal and Sprint Backlog. Both the Product Goal and the Sprint Goal help create focus and provide greater transparency towards progress. They just operate at different time horizons. I have worked with many Scrum Teams who have been using the concept of mid-term and longer-term goals as part of their Product Backlog management strategies. Breaking things down smaller is essential when you have big initiatives to tackle. It also helps you create alignment between the organization’s business strategy and goals and the direction of your product. So even though this is new, I would not consider it revolutionary or disruptive. But I do think it brings a lot of value to make it an explicit part of Scrum. How a Scrum Team uses a Product Goal in practice is up to them to decide, and it is something they will likely need to experiment with over time to see what works best for them to enable the benefits. Another key change to the 2020 Scrum Guide is the shift from “Development Team” to “Developers.” Before I get into specifics, I want to say this… This terminology update should not impact the actual implementation of Scrum and how a Scrum Team works together if you are already practicing Professional Scrum as it has always been intended. Scrum is still Scrum. The original intentions of the Scrum roles and how they work together are the same. This change helps reduce confusion and addresses anti-patterns. Having a team within a team was a bit confusing. Changing the role from “Development Team” to “Developers” helps simplify. Do the Developers still do the work of creating an Increment of value that meets a Definition of Done? Absolutely! Related to this change, there is an intention to elevate or place greater emphasis on the Scrum Team as a cohesive unit with a shared purpose. From the 2020 Scrum Guide, “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” While there are still explicit accountabilities for the Product Owner, Scrum Master, and Developers, all three roles must work together effectively in order to be successful with Scrum. We succeed as a team, and we fail as a team. Again, this is nothing new. It has always been the intention. But this wording change helps address misinterpretations and anti-patterns in how organizations implement Scrum. The best thing about the 2020 Scrum Guide is it is more clear and concise to read. A big part of the update is better organization and clarity in how the Scrum Guide reads. For example, it has always been true that Sprint Planning addresses the why, what, and how. The re-organization and streamlining makes that more clear now. In addition, things that one might consider practices or implementation details have been removed. Here are a couple of examples: The three questions for the Daily Scrum. Listing out the activities that are part of the Sprint Review. For the Scrum Nerds…. For “normal” people, you can probably stop reading here. If you are a Scrum nerd like me, I’ll point out a few more nuances of the 2020 Scrum Guide that you may be wondering about. Does the terminology change from “self-organization” to “self-management” mean anything? Not really, if you’ve been using Scrum well. These terms are used pretty interchangeably in the English language. While you can dig into more complex theories around these terms, the Scrum Guide updates were not done based on one specific theory or model. My personal theory is that the terminology change helps challenge people to think more deeply and try to remove some common misinterpretations. For example, if there are too many restrictions on the Scrum Team’s ability to manage their work and deliver high value solutions, then we need to address that. We don’t just live with boundaries that are too restrictive on Scrum Teams and say it’s okay because they still can self-organize. Instead, we actively work to remove impediments that hold Scrum Teams back. It’s about finding the right balance over time. Why is the term “potentially releasable” no longer used to describe the Increment? This has a lot to do with making Scrum more accessible and easier to understand for non-software teams. Scrum has been used for decades well beyond software, and “potentially releasable” can be confusing. I have been using the phrase “useable value” to describe an Increment when I coach non-software teams on defining their product and creating a Definition of Done. Would we still want to be “potentially releasable” every Sprint if we are a software team? Probably. I assume you want meaningful transparency to progress and quality. I assume you want to manage risk. But since everyone’s context is different (even when there is software involved), the wording change helps make this concept more approachable and understandable. Do we no longer have to plan at least one improvement from the previous Sprint Retrospective in our Sprint Backlog? The Scrum Guide no longer states this as a rule. There may be times when a Scrum Team decides not to plan any actionable improvements in a Sprint. The intention behind this change is to no longer prescribe this practice, and instead, let the Scrum Team decide. However, remember that inspection without adaptation is pointless. If your Scrum Team is not implementing improvements, they should be asking themselves why not. There are likely some underlying issues to address. Perhaps your Sprint Retrospectives are just scratching the surface, and people are not willing to have difficult conversations. Maybe you don’t have enough transparency to your process to see opportunities for improvement. Perhaps there is pressure to keep delivering more stuff. Why are there formal commitments for each artifact? Does this mean something changes? The Sprint Goal and Definition of Done have always been in the Scrum Guide. The changes made are simply to re-organize and give them a clear “home” with their associated artifact. In my training courses, there used to be confusion about a Sprint Goal and the Definition of Done being separate artifacts. And I always responded that they are not separate artifacts because they are the aspects of an artifact that help enable appropriate transparency. The biggest change as I mentioned earlier is the addition of the Product Goal, which is part of the Product Backlog. So all 3 artifacts have a clear commitment. It is now streamlined and consistent, and it helps place emphasis on the importance of transparency for effective inspection and adaptation. Conclusion: Scrum Is Still Scrum I always say in my Scrum Training that you can use Scrum well or you can use Scrum poorly. I believe the 2020 Scrum Guide update will help people more effectively apply Scrum in their context. Read the Scrum Guide. It will never be perfect, but this version is pretty great. I think you’ll find it pretty great too, even if you aren’t a Scrum nerd like me. Ready to level-up with experiential professional training? Join me in March 2020 for a PSM or PSPO live virtual course.

A free do-it-yourself workshop to help Scrum Teams articulate the paradoxical challenges they face and find imaginative solutions to navigate them.

The following are the changes that struck me the most in the 2020 Scrum Guide: "Customer" and (end) "users" (as opposed to "Scrum users" in the 2017 version) are both mentioned. I'd like to see more improvements in customer-centricity and outside-in thinking. Scrum can and should be attempted for a variety of types of knowledge work - software terms except "developer" have been removed The Development Team is dead, long live Developers - encouraging one team, even if developers commit to the Sprint Goal Experimentation is explicitly mentioned Scrum Team has 10 members or less Product Backlog Refinement is encouraged Sprint Goal found a proper home - its the commitment related to the Sprint Backlog and it's now included in the Sprint Backlog Definition of Done found a proper home - it's the commitment to the increment Scrum Values and empiricism is for the Scrum Team and people they interact with including stakeholders - stakeholders are mentioned twice as often in this version of the Scrum Guide Accountabilities of Scrum Master, Product Owner, and Developers are emphasized, thus supporting the antithesis of Patrick Lencioni's five dysfunctions of a team. Scrum Master is on the hook for the effectiveness of the Scrum Team. The Scrum Master serves the Scrum Team and the organization but is no longer referred to as a servant leader. Product Owner is on the hook for maximizing value and articulating/communicating the (new) Product Goal to support that - the Product Goal is the commitment related to the Product Backlog Developers are on the hook for delivering a useful & usable done increment that supports the Sprint Goal; there is not much point in the increment being usable if it's not useful:). Continual improvement is expected, some improvements might even go into the next Sprint Backlog, and implicitly other improvements are immediate. Sprint Planning now has three topics - the why, the what, and the how The Scrum Team is self-managing "meaning they internally decide who does what, when, and how." Anyhow that term was defined by Richard Hackman, as described on the LeSS website. Feedback is dead, long live collaboration on what to do next. The word "consistency" has made an appearance. "Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency." Overall, I like it. What do you think? Check out a discussion I had over a live stream with colleagues.

We are celebrating a long Thanksgiving weekend in the United States that stretches to Black Friday and Cyber-Monday. Reason to celebrate and give thanks and share something special with the Scrum community. Even though this Thanksgiving Special is only available within the United States, we ship our free posters from our entire Agile Poster Collection world-wide. For the first two posters, we even cover shipping & handling. Enter "1STORDER" during checkout and skip over the payment step. If you need extras or additional posters, we ship for $10 flat world-wide. What's in the Thanksgiving/Black Friday/Cyber Monday Special? 2 Scrum 2020 Posters (24x36) glossy paper 2 Scrum Sheets (8.5x11) glossy sturdy paper 2 "Agile On" Stickers One set is for you to keep and the other one for you to give away and say thanks to someone else. Enter "THANKS" during check-out to receive free shipping of: Click here to get the Thanksgiving Special