Stephanie Ockerman

In my live training, I often ask students why we estimate. The answer I usually hear is some version of...“So we know how big something is and how long it will take.”  

In my Professional Scrum Training and coaching sessions with teams, I am often asked about Product Backlog management tools. In this post, I'll share my thoughts on tools and 3 tips for using tools effectively in Scrum.

In this post, I will explain the difference between creative and reactive modes of operating, offer some examples of how this shows up in our teams and beyond, as well as some tips for cultivating your ability to stay creative.

Over the years of working in both traditional and agile environments, I have noticed a pattern. It is something I now call a culture of escalation.  In this post, I will share the common causes of a culture of escalation and some tips for breaking out of the pattern.

When I made the transition from traditional project management to agility and Scrum, I was excited to step out of the chaos and feel more purpose in my daily work.

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.

In the 2020 Scrum Guide, the Definition of Done is created by the Scrum Team. In previous versions of the Scrum Guide, this responsibility was explicitly owned by the Development Team. I will explain the intention of the change and what it means for Scrum Teams.

When I ask this rhetorical question in a training class or a coaching call, I often get knowing smiles and uncomfortable laughs.

When I first became a Scrum Master, I heard the phrase assume positive intent over and over again. And it really resonated with me.

Scrum Teams are always dealing with complex problems, unpredictability, and change.