Stephanie Ockerman

“Carryover” is not a thing in Scrum, and I think we need to stop using that terminology. Because by giving it a special name, it gets normalized. Plus the term itself is misleading. In this post, I will talk about “carryover” really means and how to handle it.

I am often asked what Scrum Teams and organizations should measure. And while measurement is important, it's not just about what we measure. It's about understanding why we measure and how we use those measures. And well, that's what actually helps you figure out what to measure. In this post, I will share some common patterns I have noticed that lead to using measures poorly. If you start to recognize some of these patterns in your team or organization, well, that's a good thing. Because seeing and understanding the problems (transparency) is the first step to improvement. And Evidence-Based Management (EBM) is a framework you can use to get back on track. 3 Ways Organizations Use Measures Poorly #1 - Measures are treated as a determination of success or failure. Yep, that's right. Measures should NOT be used as a way to determine if a team or a leader is succeeding or failing. Measures are a source of empirical information that helps guide decision-making. And the moment we make "achievement" of certain measures mean something about us in terms of our effort, our skills, or our worthiness, we risk losing the information we need to guide us in navigating complexity and unpredictability. And then making the measures "look good" becomes the goal. And if teams are chasing measures, well... you can imagine the misalignment and friction this causes across the organization. This leads us to the second common mistake. #2 - Losing focus on customer outcomes. Because we will want to measure only the things we can control, that likely means we are not measuring customer outcomes. And we are likely not creating goals that focus on customer outcomes. When teams and organizations are focused mostly on measuring activities and outputs, they are missing key information. The number of milestones achieved or budget burned (activities) does not tell you much about your ability to deliver value. And even measures like revenue or features delivered (output) does not tell you much about the customer experience. And this focus on measuring activities and outputs is likely to lead to "gaming" of the measures (whether conscious or unconscious). Essentially, we forget that we are working in complex, unpredictable environments. We cannot control customer outcomes. But we can leverage empiricism to navigate if we have transparency to what's really going on and frequently inspect and adapt our goals, our progress towards them, and our strategy. This leads us to the third common mistake. #3 - Not having a broad enough perspective of value measures. Measuring customer outcomes is a tricky business. How users respond to our products and services is influenced by many factors. We also have to consider both our short-term and long-term ability to deliver value, and quality and technical excellence come into play in this conversation. This is why EBM introduces 4 Key Value Areas (Unrealized Value, Current Value, Time to Market, and the Ability to Innovate) that enable a more robust set of perspectives to understand both market value and organizational capability. Having multiple lenses helps balance our progress towards longer-term goals and our responsiveness and effectiveness as an organization. How to Improve When I facilitate classes and coach my clients on using measures effectively, we start with understanding why we measure and identify customer outcome-based goals. And then we determine what measures (i.e. empirical information) will help us understand progress towards our goals and help us validate (or invalidate) our assumptions. We also discuss that measures can and should change over time, so this needs to be part of our inspect and adapt feedback loops. Do you want to learn how to leverage EBM to improve business agility? Scrum.org has launched an official 1-day training for EBM. It is called Professional Agile Leadership – Evidence-Based Management (PAL-EBM). In this class, you will learn how goals, measures, and experiments fit together in order to create better alignment, empower teams, and enable innovation. Join me for a public live virtual class November 1, 2021. You can also contact me to schedule a private training for your organization. What I love about having a formal training opportunity is that it brings the concepts to life in a meaningful way. It allows participants to use a case study to practice applying concepts in real-time. And when you are grounded in the foundational knowledge, you can then apply the framework more effectively in your context.

I am often asked how to create better goals. This comes up at the team level, and it also comes up for the wider organization. When we are dealing with complexity, there is no one right way, no perfect template, and no best practice. And I find it helpful to look at the goals people are using today, explore the benefits those goals are giving them, and identify if there are unintended consequences of how they are using goals. In this post, I will share some common patterns I have noticed that lead to using goals poorly. If you start to recognize some of these patterns in your team or organization, well, that’s a good thing. Because seeing and understanding the problems (transparency) is the first step to improvement. And Evidence-Based Management (EBM) is a framework you can use to get back on track. 4 Ways Organizations Use Goals Poorly #1 – Goals are not focused on customer outcomes. Instead of focusing on customer outcomes, goals may be too focused on activities and outputs. For example, a mobile app team may have a goal focused on delivering a certain subset of functionality to users (output). However, there is no guarantee that functionality will actually improve the customer’s experience. Another example is a recruiting team that has a goal focused on the number of interviews scheduled (activity). However, if they are not quality candidates, the experience is likely to be poor for everyone involved. That leads us to the next pattern. #2 – Not measuring what matters. Measures are essentially the transparent information that helps people make meaningful decisions about goals and how best to achieve them. What you measure will influence behavior. And focusing on one type of measure doesn’t give you enough understanding when working in complex environments. Often, I see organizations measuring activities and outputs but missing outcomes. The number of hours worked or budget burned (activities) does not tell you much about your ability to deliver value. And even measures like orders filled or profitability (output) do not tell you much about the customer experience. This is why EBM introduces 4 Key Value Areas (Unrealized Value, Current Value, Time-to-Market, and the Ability to Innovate) that enable a more robust set of perspectives to understand both market value and organizational capability. Having multiple lenses helps balance our progress towards longer-term goals and our responsiveness and effectiveness as an organization. #3 – Goals are not inspected and adapted frequently enough (or at all). Goals are based on assumptions. This means we should be validating our goals frequently. And of course, we need to inspect and adapt our goals as we learn more. In EBM, the concept of the Experiment Loop is introduced as a way to recognize that we make progress towards goals in a series of small experiments. And based on the results of those experiments, we must decide whether to keep going, stop, or pivot. And this includes possibly refining, updating, or even changing the goals. #4 – Focusing too much on practices for creating and aligning goals. Similar to what I teach with Scrum, there are no best practices when it comes to goals in a complex environment. And with any practice, you can use it well or use it poorly. Here are 2 insightful articles that offer an exploration of two popular practices related to goals: When Are SMART Goals Not-So-Smart? OKRs: The Good, the Bad, and the Ugly When I coach my clients on effective goals, I offer multiple ways to look at goals and encourage them not to just pick one approach or one template. You have to do what feels right in your context, and you do not want to be too rigid. Goal alignment happens through conversation and creating shared understanding – not just once a year, but frequently enough for your context. Do you want to learn how to leverage EBM to improve business agility? Scrum.org has launched an official 1-day training for EBM. It is called Professional Agile Leadership – Evidence-Based Management (PAL-EBM). In this class, you will learn how goals, measures, and experiments fit together in order to create better alignment, empower teams, and enable innovation. Join me for a public live virtual class November 1, 2021. (The first class sold out 3 weeks after registration opened, so get in early.) You can also contact me to schedule a private training for your organization. What I love about having a formal training opportunity is that it brings the concepts to life in a meaningful way. It allows participants to use a case study to practice applying concepts in real-time. And when you are grounded in the foundational knowledge, you can then apply the framework more effectively in your context.

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.