Improving For Professional Scrum

Find Out How To Continuously Improve Your Scrum Practice

Note: PMWay suggests that any Scrum team wishing to improve their "game stats" (to become Professional Practitioners of Scrum), should focus their effort 100% on the advice found below: To GET IT, to DO IT a.s.a.p!

Scrum is a lightweight framework that helps teams create valuable releasable products frequently. 
The rules that exist for Scrum practice are important to ensure transparency, to enable effective inspecting and adapting, to reduce waste, and to enable business agility.

The Scrum Value Model below shows the Vision, Product Roadmap, Release Plan and Products Released areas.  Often these "squeaky wheels," if given oil, will really help the team to "up their game stats." Achieving improvement in these core areas, sprint by sprint, is not easy to get right.  However, PMWay asserts that focusing improvements here (as soon as possible!) will be what ultimately sorts the poorly run scrum team from the great scrum team! 
Why don't you read below and see if you agree with the assertion?

Scrum Value Model

No matter how experienced, every team can improve its ability to inspect and adapt to deliver valuable Product Increments. Customers are continually evolving, and their needs are constantly changing. Competitors are continually evolving and adapting as well. Likewise, technologies are constantly changing, enabling new capabilities while also creating new challenges to overcome. New team members bring new skills and insights but may change the dynamics of the team. Meeting these challenges means not only mastering the delivery of great products by using empiricism (empirical process control is a scrum principle), but also inspecting, adapting, and improving the Scrum Team’s capabilities.

Focus on Seven Key Areas to Improve Your Scrum Practice

To help you and your teams improve, we have broken the problem down into seven key improvements:



  1. An agile mindset
  2. Empiricism
  3. Teamwork
  4. Team process
  5. Team identity
  6. Product value
  7. Organization

1.  An Agile Mindset

An agile mindset is essential to improving the attitudes and outlooks held by the members of a Scrum Team, shaping how they interpret the world and how they work with each other and the world at large. When we talk about an agile mindset, we include the Scrum values, the values and principles from the Manifesto for Agile Software Development, and Lean Principles. These values and principles guide the decisions that a Scrum Team makes, and they directly affect the effectiveness of that team in collaborating while using an empirical process to deliver valuable Product Increments.

Delivering value in a complex world means that there are few rules and no "best practices" that a team can apply.  Instead, team members are guided by an agile mindset to make decisions based on the best data available to them.

2.  Empiricism Is at the Heart of Scrum!

Scrum is designed to enable empiricism. Embracing empiricism improves transparency, inspection, and adaptation. Understanding these three pillars of any empirical process is essential for a Scrum Team to improve its ability to deliver valuable Product Increments. 
(Remember in Traditional Project Management loads of documentation and planning is used to "define the way forward."  In Agile (Scrum) this is minimized.  Therefore Empiricism is crucial to minimize risk!)

Transparency means that the Scrum Team has a full understanding of what’s going on; all aspects of the process that affect outcomes are visible to them. Transparency helps them understand which features and functions are planned for the product, how the Scrum Team is progressing toward its goals, and what value customers receive when they use the product.

Inspection means that the Scrum Team is able, at frequent intervals, to observe results and learn from new information. Team members actively seek information about both achievements and shortfalls from desired outcomes and goals.

Adaptation means that the Scrum Team, at frequent intervals, uses information obtained from inspection to change its strategy, plans, techniques, and behaviors to realign them with the desired outcomes and goals.

The Scrum Framework provides a set of lightweight rules that help a Scrum Team to achieve a minimal level of empiricism:

To truly maximize the benefits of Scrum, Scrum Teams must increase the breadth (quantity) and depth (quality) of their empiricism. For example:

3.  Mastering Scrum Means Improving Teamwork

To make empiricism work, Scrum Teams need to collaborate to deliver valuable solutions to complex problems, then measure the results, and subsequently adapt based on feedback.

An effective Scrum Team is:

PMWay suggests this video below is an example of Awesome Teamwork!

Click the image below to open another tab on your browser to view the video

TEAM operating @ Capability Maturity Level 1

An example of a team not working together!

4. To Improve, Teams Must Hone Their Team Processes

The Scrum Team defines its way of working within guard rails established by the Scrum Framework—that is, the boundaries and guidance established by role accountabilities, event goals, and artifact purposes. How the Scrum Team fulfills the roles, uses the artifacts, and conducts the events is left up to them. How they create the Product Increment and ensure quality is also left up to them.

The Team Process dimension includes practices, tools, and ways of working together. It touches on a wide variety of areas, including the following:

The practices and tools that a team uses will be influenced by the product type, its technology platform, the environment in which the product is used, the users of the product and how they use it, regulatory and legal conditions, market trends, changing needs of the business, and so forth.
That’s a lot of stuff! Moreover, much of that stuff changes over time.

As a result, Scrum Teams must remain vigilant in inspecting and adapting what they are doing, why they are doing it, how they are doing it, and what benefits they are getting from doing it. New practices and tools are continuously being created and shared in product development communities around the world, so it is important to stay connected and keep learning. In fact, teams may need to invent new practices and tools to meet their unique challenges and needs.

5. Every Strong Team has a Distinct Team Identity

A team starts as a collection of individuals. Together they form an entirely new living and breathing organism. This new organism forms an identity over time. Just as a child grows up and becomes a teenager and then a young adult, a team must constantly seek to discover and evolve its identity.

At a fundamental level, establishing identity is about answering three big questions that guide a team on its journey toward high performance:

  1. Why do we exist? (Purpose)
  2. What is important to us? (Values)
  3. What do we want? (Vision)

6.  Every Scrum Team Must Focus on Improving the Value That Its Product Delivers

The purpose of a Scrum Team is to deliver a series of valuable Product Increments. To deliver value, a Scrum Team must:

7.  The Organization Can Greatly Influence the Team’s Performance

Organizations provide both structure and culture. Both of these facets impact the teams and products that live within the organization, in either positive ways or negative ways.

Structure includes the business model, which is essentially the design for successfully operating the business. This includes the mission, the strategy, products, and services, as well as how they relate to revenue sources, a customer base, and financing. Structure also includes how employees, partners, and service providers are organized.
It often influences organizational processes and policies.

Culture is a body of habits that bind people together into a cohesive unit. Culture is a way of seeing things, of knowing what to do in specific circumstances. It evolves from the sum of all human behavior within an organization. It is often influenced by the organizational structure and processes, including roles, goals, and incentives.

The success of Scrum Teams is greatly influenced by organizational structure and culture. Maximizing the benefits of Scrum often means evolving organizational culture, processes, and possibly structure. Although you may not have to tackle these things immediately, usually Scrum Teams eventually start running into impediments that are outside of their control. They may be able to work around those impediments for a time, but this means they will reach a plateau.

Growing Scrum Requires a Team to Improve Other Capabilities

Scrum Teams need a number of capabilities to help them to continuously improve and to adapt to change. By "capability," we mean the ability to apply knowledge, skills, and experience to solve problems. Specifically, Scrum Teams must have knowledge (e.g., theory, techniques, domains), the ability to apply that knowledge skillfully to obtain desired results, and experience to build those skills as well as to guide intuition and foresight.

Scrum Teams need different capabilities depending on the kind of product they are developing and the constraints of the organization in which they work. The kinds of capabilities they need can be organized into five categories:



  1. Teaching skills
  2. Facilitation skills
  3. Coaching skills
  4. Technical excellence
  5. Servant leadership

People within the Scrum Team must have these capabilities and continue to grow these capabilities so as to be successful in the dimensions that enable Professional Scrum.

1.  Teaching Skills

Teaching is instructing others in an effort to give them new knowledge and skills. Often, Scrum Masters employ their teaching skills to help team members understand the Scrum Framework and its underlying values and principles. Scrum Teams will likely need to be introduced to techniques that can help them move forward with Scrum and become more effective with Scrum.

The skills and knowledge that a Scrum Team needs to continuously improve and tackle new challenges will change over time. Scrum Masters recognize what the Scrum Team needs based on its growth as a team and the current context to help the team get to the next level needed. This may be professional training, short exercises and knowledge sharing, a refresher course, a situational teaching moment, or a combination of all of these.

Of course, it is not always the Scrum Master who needs to teach the team. Product Owners may teach Development Teams about the product market, customer needs, and business value. Development Team members may teach each other about quality practices, testing approaches, and tools.

Teaching does not simply mean telling people things; that is, teaching is not a lecture. People learn much more effectively by doing and discovering. They learn by relating to what they already know. They also learn when the new knowledge and skills have an emotional impact.

Teaching is not something everyone can do. Some people may have an innate teaching ability, but ultimately teaching is a capability that people can develop and grow. Luckily, you do not have to be at the level of a professional teacher to employ and develop this capability.

2.  Facilitation Skills

Facilitators guide groups by using a neutral perspective to help them come to their own solutions and make decisions. The facilitator provides a group with enough structure to enable the members to engage in positive collaboration to achieve productive progress in meetings and conversations. The word "facile" is French for "easy" or "simple"; thus, a facilitator is trying to make things easier for a group of people to work together.

Facilitation skills can help improve every Scrum event. In addition, facilitation can help improve other working sessions as well as ad hoc conversations that occur when teams are doing complex work together.

The extent of facilitation can range from light to extensive, depending on the needs of the group. Wherever a meeting or conversation falls on this range, ensure there is enough structure to meet the following aims:

Any team member can help the team by facilitating. The Scrum Guide does not require the Scrum Master to facilitate all of the events; instead, facilitation is a skill that can and should be grown across a Scrum Team. Facilitation skills also help team members guide their own informal conversations and working sessions with each other to be more focused, creative, and productive.

3.  Coaching Skills

Coaching enhances a person’s ability to learn, make changes, and achieve desired goals. It is a thought-provoking and creative process that enables people to make conscious decisions and empowers them to become leaders in their own lives.

Our view is that coaching is not the same as advising or consulting. The key difference is that the person being coached is the one taking the lead. With advising, the person being advised is not learning and discovering based on his or her own experiences and desires, but rather receives advice based on someone else’s experience and desires. "Consulting" is a broad and loosely used term, but it typically involves doing the work (versus helping others discover solutions) and advising people how to do the work.

Coaching skills help Scrum Teams grow because they help the team members improve their accountability and ability to self-organize. They also help the team become more resilient when faced with complexity, new challenges, and constant change.

4.  Technical Excellence

Technical excellence means excellence in the choice and application of techniques; it is not just about the technology. Scrum doesn’t tell you how to be an excellent Development Team, nor does it tell you how to be an excellent Product Owner. The approaches, skills, and tools you will need in each role are completely dependent on the context in which you are working. Although Scrum doesn’t define what sort of things you will need to exhibit technical excellence, doing Scrum well absolutely requires that you demonstrate technical excellence. Technical excellence encompasses many things: from engineering practices to programming languages, from product management practices to quality assurance, from mechanical engineering to user experience design, and much more.

Because technology and business are changing so rapidly, along with other environmental changes that impact product possibilities, any attempt to define exactly what is needed to deliver with technical excellence would become outdated immediately. Furthermore, products are becoming much more than just software. As a result, Scrum Teams need to constantly refine and evolve what technical excellence means to them as business and technology needs change.

5.  Servant Leadership

The Scrum Guide describes the Scrum Master as a servant-leader and provides examples of ways that the Scrum Master serves the Product Owner, the Development Team, and the organization. Scrum Masters are accountable servant-leaders, which means a Scrum Master’s success is determined by the success of his or her Scrum Team. A Scrum Master helps everyone grow their capabilities, effectively navigate limitations and challenges, and embrace empiricism to deliver, on a frequent cadence, valuable products in a complex and unpredictable world.

However, there is an artful complexity to fulfilling the accountability of the Scrum Master role. When success depends on the actions of others, it is easy to want to direct them and step in when things appear to be going off-course. Yet such intervention can undermine self-organization and their feeling of accountability. This is where the capabilities of servant leadership guide a Scrum Master.

Here are examples of behaviors of accountable Scrum Masters:

These behaviors contribute to higher engagement, faster feedback, and better outcomes for the product. When managers of Scrum Teams and other leaders in the organization act as accountable servant-leaders, they support the growth of both Scrum Teams and agility across the wider organization.

A Process for Continuous Improvement

Appendix A "A Self-Assessment for Understanding Where You Are" (from Annexures in Mastering Professional Scrum 2019 OR Just the Self Assessment and Misconceptions about Scrum. I.e. only the last 2 Annexures from Mastering Professional Scrum 2019), presents a set of self-assessment questions. If you take the time with your team members to complete this assessment, it will bring additional perspectives and insights. The assessment is meant to help you identify areas where you can improve as a team; it is not meant to pass judgment on you for doing things wrong. Ideally, this tool will prompt your entire Scrum Team to look objectively at where you are and where you want to be, as a starting point for your team’s improvement.

After you have completed the self-assessment, look for questions where you scored yourself as 7 or lower. Especially look at questions where you scored yourself as 5 or lower.

The list of areas where you feel you need to improve may feel overwhelming, but as we said earlier, transparency is essential to improving the results that you will get by using Scrum. The way you start improving anything complex is to ask yourself three questions:

  1. What hurts the most? 
  2. Why?
  3. What are small experiments we can run that will deliver the most value?

What Hurts the Most?

You can’t fix everything at once. Your energy and focus will become diluted when you try to change too many things simultaneously, making it difficult to achieve anything meaningful for any one thing. When people in the organization don’t see quick benefits, they tend to lose interest and withdraw their support, and the new habits may not be given the chance to take hold. Spreading yourself across too many things also makes it difficult to measure the impacts of each change or to know which changes are having the desired impacts.

Instead, incrementally implement changes continuously over time, making adjustments as you learn more—in other words, improve empirically! Sometimes the changes will be small, and sometimes the changes must be big. It all depends on what is broken. The best place to start is usually where it hurts the most.

In Practice: Seven Common Scrum Dysfunctions:

In our experience, seven common mistakes prevent teams and organizations from fully enabling business agility with Professional Scrum. These mistakes can happen even with the best of intentions.



  1. Undone Scrum
  2. Mechanical (or Zombie) Scrum
  3. Dogmatic Scrum
  4. One-Size-Fits-All Scrum
  5. Water-Scrum-Fall
  6. Good Enough Scrum
  7. Snowflake Scrum
  1. Undone Scrum.
    In our experience with a wide variety of teams, we have found that the biggest pain point for Scrum Teams is not being able to create a "Done" Product Increment by the end of a Sprint.
    Scrum Teams that don’t produce a "Done" Increment can’t inspect and adapt and are not really getting any benefit from using Scrum. This can lead to "zombie" Scrum, or water-Scrum-fall, or several of the other dysfunctions listed in points 2 - 7 below.

    Hover your mouse over the image

  1. Mechanical (or Zombie) Scrum.
    This problem involves simply going through the motions without the spirit of continuous improvement and without understanding or caring about the underlying values and principles. This is "checking the box" to say you are doing it, but there’s no beating heart.

    zombie scrum

  1. Dogmatic Scrum.
    This issue may happen when an "expert" tells the Scrum Team the "best practices" based on his or her own experience. There are no best practices with Scrum. The assertion that teams must follow certain "best practices" discourages self-organization and ultimately limits agility. Scrum is meant to be a framework for opportunistic discovery.
    The reason Scrum is so lightweight is because specific practices and techniques are not universal. Product delivery is complex and unpredictable, and it requires creative exploration by self-organizing teams. The best practice is the practice that works for your product and your team in the current moment. And it likely won’t be a best practice for your product and your team six months from now.
  1. One-Size-Fits-All Scrum.
    In one-size-fits-all Scrum, an organization wants to standardize and create a Scrum "methodology" for all Scrum Teams in the organization. This problem, which is often combined with dogmatic Scrum, sometimes emerges more because of a (misplaced) feeling of control and predictability, rather than out of a sense of creating true value for the organization. It may represent an attempt to ensure all previous activities and documents are" covered."  In Scrum, the activities are not what matter; the outcomes are what matter. We need to be open to new ways of working to meet the real needs. Scrum is a process framework, and teams need to figure out their own process within the boundaries of Scrum.

  1. Water-Scrum-Fall.
    This problem comes in two flavors. In the first version, a Scrum Team is operating in a series of Sprints but essentially still doing a waterfall process within the Sprint, with silos of knowledge and skills and multiple handoffs. This often results in not having a "Done" Increment by the end of the Sprint.  In the second manifestation, a Scrum Team does its "development" work in a Sprint, but there are up-front requirements and design cycles and later testing cycles. This is not really Scrum at all, because there is no intention of producing a releasable Increment at the end of every Sprint.

    Hover your mouse over the image

  1. Good Enough Scrum.
    With this problem, the Scrum Team gets some efficiency benefits by regularly planning and looking at the state of the product, but it tolerates the organizational impediments and current limitations, assuming "that’s the way things have always been done." Team members don’t challenge themselves to improve technical and engineering practices to have a "Done" Increment every Sprint.

    undone scrum

  1. Snowflake Scrum.
    This situation happens when a team or organization thinks it is "unique," so it has to adapt Scrum to fit its needs. You either do Scrum or you don’t do Scrum. Modifying Scrum does not fix the problems. Modifying Scrum will likely hide your problems … for a little while. When the problems are hidden, it may feel better, but those problems are still there. Ultimately, they will manifest as a lack of business agility and dysfunction.


Root Cause Analysis

The question "why" is about getting down to the root cause. The 5 Whys is a technique used to determine the root cause of a problem by repeating the question "Why."
The "5" in the name of this technique comes from observation that typically five iterations of asking the question are needed to get to the root of the problem, although the actual number may be either fewer or more.

In Practice: Using the "5 Whys" to Diagnose Root Causes

To illustrate using the 5 Whys, consider the following problem: "Releases are constantly delayed, frustrating customers and other stakeholders."

The first question you could ask is "Why are releases constantly delayed?" Your answer might be "Because we didn’t deliver a ‘Done’ Product Increment, so our work has to continue into the next Sprint."

In response, your second question would likely be "Why didn’t you deliver a ‘Done’ Product Increment?" Your answer might be "Product Backlog items are always larger and more difficult than we think, and we don’t usually discover this until late in the Sprint."

Based on your experience you may already have thought of some possible root causes:

You can now form better questions to start digging deeper into the root causes. Your third question might be "How much transparency is there to the progress of work on a daily basis?" The answer might be "We have a Daily Scrum and look at the Scrum Board. Team members report the status for the cards they are working on. Most cards take a few days, sometimes more than a week, to get done. So it’s toward the end of a Sprint that people start reporting that they are at risk of not finishing. By then, of course, the testers don’t have enough time."

Based on our experience, possible root causes include the following issues:

Given the answers provided, ask the following kinds of questions to refine your understanding:

There are many ways this example conversation could unfold, and in practice it will take longer and require more questions to find the root causes of the problem. Major pain points are often complex and have multiple root causes. Consequently, you will have to prioritize which paths you go down first. You will start to see themes or patterns develop. Look for the root causes that are foundational, meaning they will prevent progress in solving other issues essential to the effectiveness of Scrum.

Scrum Teams can use this technique in Sprint Retrospectives to help them understand why they are experiencing a particular problem (Figure 1-1).

Figure 1-1 A sample output from a root cause analysis

A figure representing the root cause analysis report of a team is shown. The three major pain points are no "Done" increment, low product value, and releases and customer feedback delayed. They are related to each other as follows: no "Done" increment leads to releases and customer feedback delayed, which in turn leads to low product value. The possible causes for each pain point are shown. The possible causes that affect no "Done" Increment directly are, knowledge/skill silos, poor/unclear DoD, and external dependency. The possible causes that have an indirect effect are: lack of team ownership and accountability which is a result of knowledge/skill silos, scrum team not understanding scrum, and work being forced into sprint and not understood well, which is a result of PO not empowered to make decisions. The possible causes that affect low product value directly are: quality issues impacting customers, and PO focusing on PBI details only. The possible causes that affect the low product value indirectly are: poor or unclear DoD leading to progress not being transparent which further leads to quality issues impacting customers.

In Figure 1-1, a Scrum Team’s three major pain points are circled, and each possible cause is shown as contributing to one or more of the pain points. Now that they have visualized the problems and root causes, the Scrum Team can make better-informed decisions about where to start to fix the most critical issues. Although there is no magic formula to address all possible root causes, an iterative and incremental approach will allow the team to discover the best options for them at this point of time. Improving incrementally is done by employing empiricism. By discussing challenges and their possible root causes, you have created transparency and enabled inspection of that transparent information.

Experiment with Different Approaches

Complex problems don’t have simple or obvious solutions. Before you make a major investment in a particular solution, make sure that you understand the problem and have a viable solution for fixing it. Regardless of the data, intuition, and experience you have, there will always be some things that you don’t know.  To move forward without being paralyzed by these unknowns, you can try some experiments to see what might work or to gather more information.  Sounds very in alignment with navigating complexity and unpredictability, eh?

To effectively use experiments to improve, follow these steps:

  1. Identify the problem you are trying to solve. You’ve probably got some ideas about this from your root cause analysis.
  2. Create a hypothesis about some action that you think you can take to improve.
  3. Decide what you will do to test this hypothesis.
  4. Run the experiment.
  5. Analyze the results. This includes comparing actual results against expectations, reflecting on learning, and getting feedback.
  6. Refine and repeat. This may include modifying the hypothesis or the experiment. When you design the experiment, be clear about the following points:

When you design the experiment, you also want to consider the potential return on investment (ROI) of the experiment. Ideally, the experiment should be reasonably small, so you can minimize the investment and get feedback sooner. The experiment should also provide sufficient value. The low-hanging fruit may be fast and easy to pick, but you may get less return from it. The higher-value things may take more investment, time, and energy.

There is no one right answer. You have to consider your team’s unique pain points and unique needs. You have to get creative about breaking down the big stuff into smaller experiments of higher value. By doing so, you can improve iteratively and incrementally.

Now you know where you are—and you know where you want to be. As you start identifying experiments to run in an effort to move closer to where you want to be, create an improvement backlog. Order these items and begin.

In the same way that Scrum uses an empirical approach to solve complex problems and deliver valuable products, you can use an empirical approach to solve complex problems and maximize the benefits of Scrum. You can do this at the Scrum Team level and at other levels of the organization beyond the Scrum Team. For an individual Scrum Team, this cycle of continuous improvement is already built into the cadence of a Sprint and the use of a Sprint Retrospective to inspect and adapt as a Scrum Team. In addition, it is up to each Scrum Team to determine the amount of time that needs to be devoted to improvement each Sprint and how to organize and validate the improvements made each Sprint.

Success or Failure?

Is it possible for a success to be a failure? Is it possible for a failure to be a success? You may have noticed that many of the Business Agility assessment questions in Appendix A deal with outcomes (e.g., value, quick delivery). Although outcomes are most important, behaviors can also be important when they help build a team’s capabilities.

You cannot control all of the variables in complex work and the unpredictable environmental conditions around you. If you could, then you would plan everything out in advance, follow that plan, and obtain guaranteed results. In the messy real world, however, you may do all the "right things" and still not get the desired outcomes. This is why it is important to look at behaviors as well.

As you analyze the results of your experiments or improvement steps, consider both outcomes and behaviors, especially their trends over time. For example, consider the situation in which a Development Team uncovers major technical challenges with a new integration. The Development Team started this work on the first day of the Sprint because team members knew it would be more challenging and had previously learned the hard way that they should tackle the riskier items sooner. They swarmed. They informed the Product Owner of the situation and worked together to break the work down smaller. Ultimately, though, they didn’t get to "Done."

In this example, there is a clear failure: The team does not have a "Done" Increment. Yet there is also a success: The team applied learning from their previous experience and did the best they could with what they knew at the time. They collaborated, negotiated, and adapted throughout the Sprint. The key is to find new learning to do even better next time. Perhaps the team will decide to adjust how they do Product Backlog refinement to break items down in a different way. Maybe they will identify a skill gap to address. Maybe they will decide to change their development practices or tools.

Ultimately, there are two questions to ask:


The seven key improvement areas we focus on—an agile mindset, empiricism, teamwork, team process, team identity, product value, and organization—provide a lens through which you can inspect your team’s ability to achieve its goals and find ways to improve.

By looking for underlying root causes, running experiments to try to improve, and then inspecting and adapting, you can gradually, consistently, and continuously improve your ability to achieve better results.

The seven key areas also provide a lens through which you can observe outcomes and behaviors. You can look for underlying root causes, peeling the onion. This lens creates focus and clarity so that you can reflect and take intentional action.

You improve empiricism by employing empiricism. You must create transparency about the desired outcomes of the improvements and regularly inspect and adapt your way toward maximizing the benefits of Scrum.

Call to Action

Review your notes from your self-assessment questions and ratings and consider the following points:

What do you notice about the data? What trends do you see?

What new insights did you gain from this assessment?

Using what we have discussed in this chapter for guidance, hold a collaborative discussion with your Scrum Team to take the following steps:

  1. Identify the top two or three pain points.
  1. For each one, identify possible root causes.
  1. Choose two or three root causes to address.
  1. Create an ordered list of the first improvements you want to implement. For each of these "experiments," be sure to clarify expected outcomes and how you will measure results.
  1. Begin.

PMWay thanks: Mastering Professional Scrum 2019. This is truly awesome work y'all!