The Professional Scrum Competency

The Professional Scrum

Competency
The Scrum Guide

Based on Scrum.org (The home of Scrum) Página 1

The Professional Scrum Competency

THE PROFESSIONAL SCRUM COMPETENCY ................... 3 2.5.1. Teaching Principles ............................................... 48

2.5.2. Skills and Traits of a Teacher ................................ 49
1. UNDERSTANDING AND APPLYING THE SCRUM
2.5.3. When Can Teaching Be Helpful for a Scrum
FRAMEWORK ........................................................ 4
Team? ................................................................... 49
1.1. Empiricism........................................................... 5
2.6. Mentoring .......................................................... 50
1.1.1. Complex Problems and Complex Work ................... 5
2.6.1. Mentoring Principles ............................................. 50
1.1.2. Differences among simple, complicated and
2.6.2. Skills and Traits of a Mentor ................................. 50
complex problems and work ................................... 5
2.6.3. Traits of a Mentee ................................................ 51
1.1.3. Why is Scrum Important for Empiricism? ............... 6
2.6.4. Success with Mentorship ...................................... 51
1.1.4. Why is Trust Important for Empiricism? ................. 6
2.6.5. Why is Mentoring Beneficial for Scrum Teams? ... 51
1.2. The Scrum Values ................................................ 7 3. MANAGING PRODUCTS WITH AGILITY ..................53
1.2.1. Values ..................................................................... 7
1.2.2. The Scrum Values.................................................... 7 3.1. Forecasting and Release Planning ....................... 54
1.2.3. The Importance of Living the Scrum Values ............ 8 3.1.1. Forecasting ........................................................... 54
3.1.2. Release Planning................................................... 54
1.3. Scrum Team ........................................................ 8
3.1.3. Forecasting, Release Planning and Complexity .... 54
1.3.1. Product Owner ........................................................ 9
3.1.4. Forecasting Techniques ........................................ 54
1.3.2. Developer.............................................................. 14
3.1.5. Release Planning Techniques ................................ 56
1.3.3. Scrum Master ....................................................... 15
3.1.6. Conclusion to Forecasting and Release Planning .. 56
1.4. Scrum Events ......................................................16
3.2. Product Vision .................................................... 57
1.4.1. The Sprint .............................................................. 18
3.2.1. Business Strategy and Product Vision ................... 57
1.4.2. Sprint Planning ..................................................... 20
3.2.2. Product Strategy and Product Vision .................... 57
1.4.3. Daily Scrum ........................................................... 23
3.2.3. Characteristics of a Product Vision ....................... 57
1.4.4. Sprint Review ........................................................ 25
3.2.4. Communicating the Product Vision ...................... 58
1.4.5. Sprint Retrospective .............................................. 27
3.3. Product Value..................................................... 59
1.5. The Scrum Artifacts ............................................29
3.3.1. Common Mistakes to Avoid when Seeking
1.5.1. Product Backlog .................................................... 29
Product Value ....................................................... 59
1.5.2. Sprint Backlog ....................................................... 31
3.3.2. What makes a product valuable? ......................... 60
1.5.3. The Increment ....................................................... 34
3.3.3. How can Product Value be measured? ................. 60
1.6. Definition of Done ..............................................35 3.3.4. How do you know when you’ve delivered enough
1.6.1. Characteristics of the Definition of Done .............. 35 Product Value?...................................................... 61
1.6.2. Frequently Asked Questions about being Done .... 36 3.3.5. How do you know if there is more Product Value
2. DEVELOPING PEOPLE AND TEAMS ........................ 39 to pursue? ............................................................. 61
2.1. Self-Managing Teams .........................................39 3.4. Product Backlog Management ............................ 61
2.1.1. Characteristics of Self-Managing Scrum Teams ... 40 3.4.1. The Importance of Effective Product Backlog
2.1.2. Myths about Self-Management ............................ 41 Management ........................................................ 62
3.4.2. Product Backlog Management Activities .............. 62
2.2. Leadership Styles ................................................42 3.4.3. Tips for Effective Product Backlog Management.. 64
2.2.1. The Difference Between Leaders and Managers .. 42
2.2.2. What are Leadership Styles? ................................ 42 3.5. Business Strategy ............................................... 65
2.2.3. An Agile Leadership Style ...................................... 42 3.5.1. Scrum and Business Strategy ................................ 66
2.2.4. A Word about “Servant Leadership”..................... 43 3.5.2. Evidence-Based Management (EBM) and
Business Strategy .................................................. 66
2.3. Facilitation..........................................................43
2.3.1. Facilitation Principles ............................................ 43 3.6. Stakeholders ...................................................... 67
2.3.2. Skills and Traits of a Facilitator ............................. 44 3.6.1. Identify and Learn about Key Stakeholders .......... 68
2.3.3. Why is Facilitation Beneficial for Scrum Teams? .. 44 3.6.2. Common Challenges in Stakeholder Engagement 68
2.3.4. Facilitation techniques for Scrum Events .............. 45 4. DEVELOPING AND DELIVERING PRODUCTS
2.4. Coaching.............................................................45 PROFESSIONALLY .................................................70
2.4.1. Coaching Principles ............................................... 46 5. EVOLVING THE AGILE ORGANIZATION ...................72
2.4.2. Traits of a Coach ................................................... 46
2.4.3. Coaching Skills ...................................................... 47
2.4.4. Why is Coaching Beneficial for Scrum Teams? ..... 47
2.5. Teaching .............................................................48

Based on Scrum.org (The home of Scrum) Página 2

The Professional Scrum Competency

The Professional Scrum Competency

Scrum.org has created these Professional Scrum Competencies to help guide an individual’s personal development.
They also provide an excellent model for assessing the capabilities of a team within an organization. Everything that
Scrum.org does, including our courseware, certification tests, and content, is designed with the competencies in mind.
Building proficiency with Scrum starts with the fundamentals, Understanding and Applying the Scrum Framework as
the foundation which the other competency areas build upon.
The competencies and their Focus Areas apply to the Scrum Team (Product Owner, Scrum Master, and Developers)
and other organizational roles, such as Agile Leaders. Organizations can benefit from using a common understanding
of the competencies and focus areas to evaluate and balance their team’s proficiencies based on their unique needs.

1. Understanding and Applying the Scrum Framework

Scrum helps people and teams deliver value incrementally in a collaborative way. As an agile framework,
Scrum provides just enough structure to integrate the framework into how the team works and requires
teams to add the correct practices for their situation as they build out the processes. Scrum is based on
empiricism, self-management, and continual improvement. The competency includes the focus areas of:
Empiricism, Scrum Values, Scrum Team, Events, Artifacts, Done, and Scaling.

2. Developing People and Teams

Scrum is all about working together to deliver products with greater agility. To achieve success, the
members of the Scrum Team may take on different stances as they work with people inside and outside of
the team. These stances are focus areas for this competency and include:
Self-Managing Teams, Facilitation, Leadership Styles, Coaching, Mentoring and Teaching.

3. Managing Products with Agility

Products are how Scrum Teams provide value to their users and the organizations they work for and with.
A Product has a clear goal, stakeholders, and users. The value of the product is measurable. Effectively
managing products in an agile environment requires the following focus areas:
Forecasting & Release Planning, Product Vision, Product Value, Product Backlog Management, Business
Strategy, and Stakeholder & Customers.

4. Developing and Delivering Products Professionally

Using Professional Scrum results in high-quality products delivered iteratively and incrementally with
relatively high frequency. These products meet the needs of stakeholders and customers and provide
flexibility for both early value realization and adaptation to changing needs. To meet these needs means
that the Products should be developed in a certain way. The following focus areas support this
competency:
Emergent Software Development, Managing Technical Risk, Continuous Quality, Continuous Integration, Continuous
Delivery, and Optimizing Flow.

5. Evolving the Agile Organization

The majority of Scrum Teams are operating within an organization. For Scrum Teams to succeed, they
require that organizations reduce friction and provide the freedom that they need to be self-managing and
create solutions closest to the work. To support this agility, organizational structure, incentives, human
resource practices, and governance must enable rather than deter agility. The focus areas include:
Organizational Design and Culture, Portfolio Planning, and Evidence-Based Management.

Based on Scrum.org (The home of Scrum) Página 3

The Professional Scrum Competency

1. Understanding and Applying the Scrum Framework

One of the first steps a Scrum practitioner should take is to learn about the Scrum framework. The Scrum Guide is the
foundational body of knowledge for the Scrum framework. The Nexus Guide builds upon that foundation as the body
of knowledge for the Nexus scaling framework.
To help practitioners advance their use of Scrum, the Understanding and Applying the Scrum Framework dives deeper
into Scrum theory and the Scrum framework. The Focus Areas in this Competency explore the purpose of each of these
elements and provide practical advice on how to use Scrum to increase the effectiveness of individuals, teams and
organizations.
This competency has the following key focus areas:

1. Empiricism
In Scrum, empiricism refers to the idea that solving complex problems, or doing complex work, can only be done using
an exploratory process rather than relying on predetermined plans. Learn about empiricism and complex work. Explore
why trust is important for empiricism to thrive.

2. The Scrum Values

For agility to thrive, the culture of the organization must support the fundamental concepts of agility. The Scrum Values
- Focus, Respect, Openness, Commitment, and Courage - create an environment where empiricism, self-management
and continual improvement are more successful.

3. The Scrum Team

The Scrum Team is a small unit of professionals focused on attaining the Product Goal. Scrum Teams consist of a
Product Owner, Scrum Master and Developers. Each has a clear set of accountabilities. Learn more about the Scrum
Team, accountabilities, responsibilities and why these aren’t called “roles.”

4. The Scrum Events

The five Scrum Events provide regular opportunities for enacting the Scrum pillars of Inspection, Adaptation and
Transparency. In addition, they help teams keep aligned with the Sprint and Product Goals, improve Developer
productivity, remove impediments and reduce the need to schedule too many additional meetings.

5. The Scrum Artifacts

Learn about the three Scrum artifacts and their commitments: Product Backlog and Product Goal; Sprint Backlog and
Sprint Goal; Increment and Definition of Done. Explore some common antipatterns and myths that surround these
artifacts.

6. Definition of Done
The Definition of Done describes the quality standards for the Increment. Learn why getting to Done is so important,
what undone work is, if it’s okay to show work that isn’t done to stakeholders, can you present undone work at the
Sprint Review and what’s the difference between the DoD and Definition of Ready or acceptance criteria.
Scaling
Scrum is designed to work at the team, product, and organization level. The practitioner will be able to apply Scrum in
increasing levels of complexity and scale. They will be able to demonstrate when to scale and when not to scale and
appreciate scaling practices and complementary frameworks that help organizations scale Scrum. The ultimate level of
proficiency within this Focus Area is the ability to know what, and what not, to compromise in pursuit of a scaling
approach by understanding the trade-offs and benefits of particular concepts and practices. Ultimately, the practitioner
will demonstrate that they can scale Scrum and still keep its essential qualities of empiricism, self-organization, and
continuous improvement. The practitioner should also be able to demonstrate the results of good scaling practices
from both an organization and business perspective.
Based on Scrum.org (The home of Scrum) Página 4
The Professional Scrum Competency

1.1. Empiricism
Empiricism is the philosophy that all knowledge originates in experience and observations. It’s a cornerstone of the
scientific method and underlies much of modern science and medicine.
Among philosophers, empiricism is contrasted with rationalism, where rationalism is the perspective that knowledge
is developed by reason, analysis or thinking things through.
When agilists refer to empiricism, we are simply recognizing that there are categories of problems that are too complex
to be solved by reason or analysis alone. While simple problems are straightforward to solve, complex problems require
that we experiment our way to the solution.
In the context of Scrum, empiricism refers to the idea that solving complex problems, or doing complex work, can only
be done using an exploratory process rather than relying on predetermined plans.

1.1.1. Complex Problems and Complex Work

Complexity science is a discipline unto itself and it’s worthwhile to study it in order to gain a deep understanding of
how to make sense of a very complex world.
However, for our purposes we can think of complex problems as those with many “unknown unknowns.” That is, there
are aspects of the problem that we either haven’t identified or that will surprise us because they turn out differently
than what we expected.
In complex problems, we don’t know what we don’t know, and we don’t know what they are until we encounter them.
We contrast complex problems from those that are simple and those that are complicated.

1.1.2. Differences among simple, complicated and complex problems and work
We can think of simple, complicated and complex
problems as a continuum going from
• simple (where most things are known)
• to complicated (where we know what we
don't know)
• to complex (where we don't know what we
don't know)

Simple Problems
Simple problems are those where we have a clear understanding of the problem and the solution is easily developed.
When our work is simple, it’s because we fully understand what we’re tasked to do and we know how to do it.
We can identify whether we’re engaged in simple problems or simple aspects of our work because:
• most things are known about the problem and solution
• they can be solved using well-established methods
• if we've solved this problem before, we can do it again roughly the same way
• if we haven't done it before, the solution is easy to figure out because we understand everything about the
problem and how to create a solution
• we can create a plan of the tasks need to solve the problem
Examples:
• Software: run a build that succeeds consistently. (Note that if the build fails for non-obvious reasons, this
problem can become either complicated or complex)
• Medicine: treat an upset stomach
• Home: bake cookies; shop for groceries

Based on Scrum.org (The home of Scrum) Página 5

The Professional Scrum Competency

Complicated Problems
Complicated problems are those where we have agreement on the problem, but the solution is ill-defined. That said,
if we find experts in the problem domain, they can create a solution to the problem.
In product development or other work, we generally understand what we’re tasked to do and we can figure out how
to do it if we have the right expertise on the team.
We can identify whether we’re engaged in complicated problems or complicated aspects of our work because:
• there are aspects of this problem that are unknown or that we don’t understand, but we know what they are
and we will turn the unknowns into knowns through analysis
• we have solved a similar problem before, so experts can figure out how to solve this one
• we can predict the outcome of specific actions after we analyze the situation
• we can create a template of most of the tasks to execute to solve the problem
Examples:
• Software: fix a non-trivial bug; extend a feature
• Medicine: diagnose a blockage and perform surgery to place a stent in an artery
• Home: buy a house; save for retirement

Complex Problems
Complex problems are those where we don’t have agreement on the problem or the solution. With complex problems,
the variables involved are so intertwined that when we change one variable, it has an impact on others. This results in
us being unable to predict all the cause-and-effect relationships, we can only explain them in hindsight.
At the beginning of complex product development or complex work, we generally don’t know exactly what the final
product will be and we certainly don’t know exactly how to create it. There are many unknowns that are unknown and
we’ll encounter them along the way.
We can identify whether we’re engaged in complex problems or complex work because:
• we don’t know what we don’t know and we won’t know what they are until we encounter them
• we are often surprised by what we uncover
• they have a large number of interdependent variables, many of which are uncertain and can result in multiple
potential solutions
• they cannot be solved through linear or predictable means
• we haven't done this before and we’re not even sure if there is a way to do it
• we don't really know exactly what the problem or solution is
Examples:
• Software: create a new product for a new market
• Medicine: find a cure for pancreatic cancer
• Home: raise children

1.1.3. Why is Scrum Important for Empiricism?

Scrum encourages teams to continuously experiment, inspect and adapt their work. So if a team is faced with complex
problems or complex work to do, Scrum provides a framework for teams to use empirical techniques. Scrum isn’t the
only way to solve complex problems, but it is an excellent way to do so.
Scrum utilizes three pillars to support this approach: transparency, inspection and adaptation.
• the team must be transparent about their progress and the product being developed
• they must inspect this progress and the product regularly
• and they must be able to adapt their work and processes based on what they observe
This helps to ensure that the team is continuously improving and delivering value to the customer.

1.1.4. Why is Trust Important for Empiricism?

Based on Scrum.org (The home of Scrum) Página 6
The Professional Scrum Competency

Teams that work in an empirical way are continually taking risks, creating innovative ideas and providing feedback.
Without having trust on the team, members may become reluctant to take those risks or offer their alternative ideas.
Without trust, team members may act in ways that will avoid critique. In particular, they may feel a need to spend a
lot of time analyzing or planning, rather than feeling free to experiment.
When teams experiment, they make and test hypotheses. If the experiment “fails,” it’s not a failure of the team or the
person that proposed it, it’s simply that the hypothesis was not supported. The experiment itself was a great success,
because the team learned something valuable and is further down the path of solving their problem. Understanding
this aspect of experimentation and feeling supported when the experiment “fails” is an important leadership mindset
shift when adopting Scrum.

1.2. The Scrum Values

1.2.1. Values
Values are the principles we view as important in the way we live and work. They are the core beliefs that guide our
actions, behavior and decisions. Examples of personal core values may include: family-first, honesty, kindness,
patience, authenticity and many others. Understanding our personal values helps us understand what’s important to
us. Using our values to guide our behavior, actions and decision-making provides us a sense of direction and purpose.
The Scrum Framework articulates a set of Scrum Values to help guide the work, actions and behavior of Scrum Team
members.

1.2.2. The Scrum Values

The Scrum Values are:
• Courage - Scrum Team members need courage to do the
right thing and face tough problems. For example, they
should exhibit courage to explore the unknown, to change
direction, to share information and to engage in
courteous disagreements.
• Focus - The Scrum Team focuses on the work of the Sprint
and its goals. Examples of this include focusing on:
creating value, what’s currently most important and
getting to Done.
• Commitment - Each Scrum Team member commits to
achieving the team’s goals and to support each other. This involves commitment or dedication to:
o Delivering value;
o Quality;
o Working toward the Sprint and Product Goals;
o Using empiricism.
• Respect - It’s necessary for Scrum Team members to respect each other as skilled professionals. Scrum Team
members should respect each other's differing expertise and perspectives and be respectful when they
disagree.
• Openness - The Scrum Team and its stakeholders agree to be open about all of the work and the challenges
with performing the work. Scrum Team members should be open about the struggles they face. They should
share feedback and learn from each other and from their stakeholders.
Each of the Scrum Values may be interpreted by each team member differently. Language and cultural differences may
contribute to this. Gunther Verheyen, a Professional Scrum Trainer created a well-regarded description of the Scrum
Values. On thescrumvalues.org you’ll find this description and its translation into over two dozen different languages.
We recommend that Scrum Teams routinely collaborate on what the Scrum Values mean to their team. Scrum Teams
should explore what these values mean to each individual on the team and collaborate on how these values can work
on a team level. The following blog provides an example of how to conduct a Scrum Values workshop.
Based on Scrum.org (The home of Scrum) Página 7
The Professional Scrum Competency

1.2.3. The Importance of Living the Scrum Values

The Scrum Team accountabilities, events and artifacts provide structure for practicing Scrum. Some practitioners
mechanically follow this guidance without adopting an agile mindset. They tend to gloss over the Scrum Values and
dismiss them as being emotional and unbusiness-like. These teams tend not to: discuss the Scrum Values, learn how
each member of the team defines the Scrum Values, nor do they apply the Scrum Values as they work together. These
teams do not practice Professional Scrum.
Scrum and an agile mindset, requires a shift away from command-and-control style corporate behaviors. The Scrum
Values provide support for this mindset shift and foster an environment of support, professionalism and trust necessary
for practitioners to practice Professional Scrum. The Scrum Values:
• Help create an environment of psychological safety that is necessary for empiricism to thrive.
In traditional environments, it’s typical to assign blame when things don’t go as planned. However, in Scrum we
understand that complex problems can only be solved by experimentation and we cannot plan our way to the solution.
The essence of experimentation is to create a hypothesis, and either prove or disprove it. A great deal of knowledge is
gained when a hypothesis is disproved. Scrum Team members must trust that they will be supported, not blamed,
when an experiment doesn’t support their hypothesis.
• Provide a guide for decision-making.
When faced with several difficult choices, it’s helpful to lean on the Scrum Values to help assess whether each choice
is in alignment or not.
• Support strong team dynamics.
The Scrum Values help guide interpersonal interactions among Scrum Team members to be healthy and supportive.
This helps team members feel motivated and supports an environment of creativity.

1.3. Scrum Team

A Scrum Team is a small (typically 10 or fewer) team of people that work together, using the Scrum Framework, to
create something valuable. The team consists of:
• A Product Owner who maximizes the value of the product that results from the work of the Scrum Team
• Developers who create the product
• A Scrum Master who helps the team improve its practices and effectiveness
Everyone on the Scrum Team is accountable for certain aspects of the team’s work. The Scrum Team as a whole is
accountable for creating a valuable, useful Increment every Sprint and the Product Owner, Developers and Scrum
Masters each have accountabilities that are specific to them.

Key Characteristics of Scrum Teams

In order for a Scrum Team to be successful, they should be:
• Cohesive - They should work together as a tight-knit collaborative team, supportive of one another and
fostering trust among team members
• Focused - Scrum Teams are focused on creating value and achieving the Product Goal
• Cross-functional - The team consists of individuals with the diverse set of skills and experience needed to
accomplish their goals
• Self-managing - They are empowered by the organization to determine how to do their work without being
directed
• Non-hierarchical - They act as one team, with no sub-teams or organizational hierarchy
• Accountable - The entire team is accountable for the success in creating a valuable, useful Increment every
Sprint

Accountability, Responsibility and Roles

The Scrum framework describes Scrum Master, Product Owner and Developers as “accountabilities” and not “roles.”
Based on Scrum.org (The home of Scrum) Página 8
The Professional Scrum Competency

This puts emphasis on the fact that Scrum Teams are results-oriented, with clear accountabilities among team
members, rather than an organizational construct.
Product Owner, Scrum Master and Developer do not have to be “roles.”
The word “role” often refers to a particular job or job title. In the 2020 release of the Scrum Guide, the term “role” was
replaced with “accountabilities” to emphasize an ownership mindset necessary to execute Scrum well. The Scrum
framework provides guidance on how to use Scrum effectively, it has nothing to do with organizational constructs like
job titles.
Scrum practitioners distinguish between “accountability” and “responsibility.”
This can be confusing at first since colloquial English use doesn’t have a strong distinction between these words and
some spoken languages do not have these separate concepts. However, Scrum uses definitions typically used in
business communication:
• Responsibility - the obligation to perform a task. Responsibility is often about accomplishing the work and
creating its output.
• Accountability - taking ownership of the results, or outcome, of the work. The willingness to bear the
consequences and be answerable for the choices made.
Responsibility to do something may be delegated, but accountability for the result generally cannot. For example, the
Product Owner is accountable for effective Product Backlog management, however they may delegate responsibility
for doing some of this work to others.
When everyone is clear on what they are accountable for, the team functions well.
In Scrum there are four high-level areas of accountability:
• Creating a valuable, useful Increment: the entire Scrum Team
• Maximizing the value of the product: Product Owner
• Creating the product: Developers
• The effectiveness of the Scrum Team: Scrum Master

Common questions about accountabilities

• Is it wrong to use the word “role” when referring to the Scrum Master, Product Owner or Developers?
No, it’s ok to use “role” in casual conversation, just as long as we recognize that this is language shorthand and that
they are actually sets of accountabilities.
• What is an example of the difference between job title and Scrum accountability?
Sometimes the person on the Scrum team that is accountable to the team for maximizing the value of the product
(Product Owner) has job titles such as Product Manager or Business Analyst. They may also have the job title of
“Product Owner,” Scrum doesn’t disallow this.
• If these aren’t roles, can someone have the accountabilities of both a Product Owner and a Developer, for
example?
The answer to this depends on the particular circumstance. The Scrum framework doesn’t prohibit this, however the
skills and expertise needed to successfully execute more than one of these sets of accountabilities are difficult to
embody in one person. We suggest against this if possible.

1.3.1. Product Owner

Those very new to Scrum may read these accountabilities and conclude that it is a very tactical job, centered around
administration of the backlog. Nothing is further from the truth!
The Product Owner owns the product vision. They play a crucial role in guiding the rest of the Scrum Team toward a
shared understanding of the product’s value, purpose, goals and direction. A professional Product Owner uses both
agile product management and Scrum skills to fulfill their responsibilities:
• Product Owners use agile product management skills and techniques to manage the product lifecycle and its

Based on Scrum.org (The home of Scrum) Página 9

The Professional Scrum Competency

long-term business objectives. Examples include: market research and competitive analysis; product strategy;
product roadmapping; acting as the voice of the customer; engaging with stakeholders; maximizing revenue
and return on investment; product launch; and product retirement.
• Product Owners Scrum and the elements of the Scrum framework to deliver on their vision of the product. For
example: applying empiricism and experimentation for product and value discovery; crafting concrete,
actionable and measurable Product Goals to provide focus for the Scrum Team; and using strong backlog
management techniques to help communicate steps toward the Product Goal.
In order to maximize the value of the work of the Scrum Team, the Product Owner must provide timely decision-making
and guidance to the team. This requires that the accountabilities of the Product Owner and the outcome of the work
the team does, rest with one person. They cannot be distributed across several people or a committee. However, the
Product Owner may delegate the responsibility of doing the work to others.

Characteristics of a Product Owner

A Product Owner works to maximize the value of their product with the rest of the Scrum Team. To be effective in this
accountability, a Product Owner must be strategic and resilient. They possess a combination of communication and
analytical skills that allows them to drive a clear vision, make decisive decisions, foster collaboration and drive
continuous improvement in order to advocate for their customers in creating a successful product.

9 Ways a Product Owner Can Be More Effective

Working as a Product Owner is both a dynamic and challenging experience. The accountability is multifaceted and
demanding, requiring a range of skills, qualities and experience. Product Owners need to consider behaviors and skills
beyond the core of Agility and the Scrum framework as described in the Professional Scrum Product Owner™ -
Advanced Training and the preferred "stances" of a Product Owner.
Ultimately, a Product Owner is effective when the work of the Scrum Team maximizes the value of the product. Let’s
explore what this entails.
1 Lead with the customer and user in mind
For a Product Owner to be effective at maximizing the value of their product,
they should have a deep understanding of the customer's and user’s needs,
pain points and goals. This helps them and the rest of the Scrum Team focus
on customer outcomes when approaching product delivery.
The Evidence-Based Management concept of Unrealized Value can help with
understanding whether a product is valuable. Unrealized Value is the gap
between the outcomes that customers currently experience and the
outcomes that they would like to experience. This gap represents market and
product opportunities that the organization and teams can pursue. It can be
described as a “satisfaction gap” between current and desired experiences.
Valuable product Increments reduce the size of the satisfaction gap, and
reduce the Unrealized Value of the product.
As the Scrum Team works to develop and deliver value to customers, make sure that as a Product Owner, you are not
a bottleneck between the Developers and the stakeholders, which includes customers and users. In fact, you can even
take on a facilitator role to encourage collaboration between Developers and customers. Gaining insights about
customer satisfaction, needs and challenges and potential future opportunities are invaluable for anyone on the Scrum
Team. There are multiple ways Scrum Team members can engage with their customers and users in order to get to
know them better. You can learn more about how to understand their concept of value, needs and problems in the
resource “Ways to Understand Customer and User Needs.”
2 Steer with product vision, strategy and goals
Product Owners own and lead the product vision and strategy. To do so, you must manage and maximize the value of
your product as a visionary, focusing on the future and the opportunities the product could accomplish to satisfy the

Based on Scrum.org (The home of Scrum) Página 10

The Professional Scrum Competency

unmet needs of current and potential customers. When you hold and communicate a captivating vision for the product
you are able to inspire the team and stakeholders to align around a better future for the product.
With this product vision, you create a shared understanding of the product strategy and use goals to help the
organization move closer to it in an empirical way. Taking an empirical approach allows the Scrum Team to adapt their
next actions based on feedback and evaluate if their goals are still relevant. The following goal structure that supports
an empirical approach as described in the Evidence-Based Management framework.
• Strategic goals outline the direction for reaching the vision, they are however aspirational goals and the steps
necessary to reach it are filled with unknowns. To work toward a goal with many uncertainties on its path, the
Scrum Team will need a series of more practical targets, such as intermediate goals.
• Intermediate goals are achievements that move the Scrum Team closer to the strategic goal. The path to an
intermediate goal is still uncertain, but not completely unknown, for example the Product Goal. To allow
frequent inspection of progress toward this intermediate goal, and timely adaptation when needed, Scrum
Teams apply tactical goals.
• Tactical goals are critical near term objectives that help a team move toward the intermediate goal. A tactical
goal could be, for example, a Sprint Goal.
Consider the following example:
A brick and mortar grocery chain store has been trying to encourage their customers to shop with them via their new
online website. They think it offers convenience which could bring in more repeat revenue and is also a way for the
store to capture new customers. However, they notice that many of their customers are reluctant. Customers are
worried that they could receive damaged produce and goods in the online experience.
Their goals are the following:
Strategic goal: Our long-term objective is to make it easy and reliable for customers to buy groceries from us online.
We know we will have achieved this when we see a 20% increase in customers purchasing groceries online.
Intermediate goal: Our near-term objective is to make existing customers feel confident that they will receive fresh,
quality products and goods when shopping in our online store. We know we will have achieved this when we see an
increase in customer confidence score rise from an average of 2.5 to a 3 or above.
Tactical goal: Our short-term objective is to increase the freshness and quality of produce and goods customers receive
in their orders. We know we will have achieved this when we see a 25% decrease in requests for refunds and credit
from purchases.
3 Understand your product and product management fundamentals
A Product Owner who understands their product makes better informed decisions, communicates more effectively
with stakeholders and Developers, and ultimately delivers a product that delivers value by meeting the needs of the
customers and users.
Here are some questions Product Owners need to continuously explore as they delve deeper into understanding their
product.
• What is our product vision?
• What problems does it solve for our customers and users?
• What makes our product valuable? What is our value proposition?
• Who is the target market? Who are the product’s (potential) users? What are their needs? What are their pains?
What is their satisfaction gap?
• What is our Product Goal? Which next product features might bring us closer to that goal?
• What technologies and tools are used to build the product, and what are their strengths and limitations?
• Where is the product in its product life cycle? How can we adapt strategies and priorities based on the product's
lifecycle stage to ensure its continued relevance and value to customers?
• Are our product or product features still worth pursuing? Are we in danger of sunk fallacy? Should we continue,
pause or abandon the product or features based on the evidence we have gathered so far?
• Who are our competitors? What other products are out there that meet the same need as our product? What
are their strengths and weaknesses?
Based on Scrum.org (The home of Scrum) Página 11
The Professional Scrum Competency

• How are we measuring product value? What value do we deliver to our customers and users today? And what
value could be realized if we would realize all potential needs of our customers and users?
4 Focus on creating value through experimentation
Scrum Teams don’t know the value of the work they’ve done until they put it in the hands of their customers, until
then value is just an assumption. They might believe certain product features will be valuable for their customers, but
they can only validate it when people are actually using it. That’s why Scrum Teams should take a hypothesis-driven
approach and treat their work in a Sprint as experiments.
As a Product Owner, encourage experimentation by using the Sprint as a short feedback cycle in which the Scrum Team
has the opportunity to validate and test the assumptions they have about the product and customer needs. This
reduces the risk of the Scrum Team building a product nobody wants or needs and allows the Product Owner to adapt
the Product Backlog to maximize the value of the product. Being open to experimenting and adapting to evolving
circumstances is key to maximizing product value based on continuous learning.
The Evidence-Based Management (EBM) framework can help Product Owners and Scrum Teams measure, manage and
increase the value they derive from their product delivery.EBM helps teams to focus on improving outcomes, reducing
risks, and optimizing investments.
5 Foster transparency and communicate effectively
An effective Product Owner fosters an environment of transparency and open communication, ensuring that
stakeholders are aware of the product's progress, challenges, and successes. To help to create this level of transparency
the Product Owner should ensure the Product Backlog is managed, ordered and aligned with the Product Goal. An
ordered Product Backlog also helps everyone know what the next valuable items are to work on and pursue. When this
doesn’t happen, the Scrum Team risks having a bloated backlog. The more items on the Product Backlog, the more
difficult it is for stakeholders and the Scrum Team to decipher what is important to pursue. As a result, transparency is
lost and eventually the Product Backlog becomes a counterproductive communication tool that is wasteful to manage
and refine. Therefore, It is essential the Product Owner makes conscious choices of what does NOT go on the Product
Backlog and communicates this in a clear and respectful way to the team and stakeholders.
Good communication skills are also needed to ensure transparency. As a Product Owner you not only need to
understand who to communicate with, when and how, but you also should ensure everyone has a shared
understanding of the product vision, strategy, goals, and the Product Backlog. This includes not only articulating your
ideas but also actively listening to feedback and incorporating valuable insights from stakeholders, including customers
and users.
6 Build and maintain stakeholder relationships
A Product Owner represents and is the voice of all stakeholders. This includes deciding what next items of value the
Scrum Team should work on next. Having a sole representative helps to overcome a lack of stakeholder consensus and
ensures decisions are not slowed down.
Keep in mind that while the Product Owner is the ultimate decision maker, they should leverage the knowledge and
expertise of those around them so they can make well informed decisions. For this they need to build strong
relationships with their stakeholders based on trust and openness and also encourage collaborative relationships
between the Scrum Team and the stakeholders. The Sprint Review is a great opportunity to do that. During the Sprint
Review, the Scrum Team and stakeholders come together to inspect progress toward the Product Goal, and discuss
market trends and challenges the team is facing. This type of collaborative discussion helps build a foundation of
transparency and trust between the Scrum Team and stakeholders.
7 Take a collaborative approach
The Product Owner accountability requires knowledge, skills and experience in areas such as product strategy, market
research, business modeling and finance, innovation, stakeholder collaboration and product backlog management. It
would be impossible for one person to carry out all the activities in these areas all by themselves. Effective Product
Owners don’t work in isolation, they collaborate with the Scrum Team and stakeholders, including customers and users,
in order to leverage their collective intelligence to find more innovative solutions that bring value to the customer.

Based on Scrum.org (The home of Scrum) Página 12

The Professional Scrum Competency

Product Owners build up trust within the Scrum Team and are comfortable delegating activities to their peers. As a
Product Owner you might decide to delegate responsibilities of certain elements of Product Backlog management to
the Developers. For example, you may choose to delegate the creation and communication of new Product Backlog
items to the Developers. This type of collaboration allows a Product Owner to spend more on other areas, such as
value proposition, strategy and goals.
To identify and clarify responsibilities, try facilitating a session using delegation poker from Management 3.0
with the team. This can be a great way to agree on what is delegated to others.
8 Facilitate toward value
Facilitation in Scrum is often seen as a Scrum Master responsibility. However anyone in the team can act as a facilitator,
and it is an especially good skill for a Product Owner to develop.
Here are some situations in which a Product Owner’s facilitation skills come in handy:
• To facilitate interactions and enable strong collaboration between a variety of stakeholders and Developers
• To create an environment where everyone feels inspired to share feedback and ideas
• To gather and incorporate valuable feedback from stakeholders, including customers and users in Sprint
Reviews
• To make better informed decisions by leveraging the expertise, experience and perspectives from others
• To gain strong buy in on an idea or initiative
• To lead effective meetings and workshops with stakeholders from different backgrounds.This may include
events such as the Sprint Review.
Everyone in the organization should respect the Product Owner’s decisions for the product, creating shared
understanding, exploring diverse opinions and ideas. Additionally, achieving strong buy-in among stakeholders and the
Scrum Team can have a great impact on the success of the product. Effective facilitation can help a Product Owner
with these interactions.
9 Be decisive
A Product Owner is the ultimate decision maker, meaning that they are empowered to make final decisions for the
product. This includes decisions related to product vision, strategy, goals and the Product Backlog. In addition, a
Product Owner’s ability to make informed and definitive decisions is essential in a fast changing environment. They
should be able to evaluate alternatives, analyze trade-offs, and make choices that maximize product value swiftly.
They also must be able to say "no" in order to maintain focus on high-value product features.
While the Product Owner is the final decision maker, remember to involve the rest of the Scrum Team in decision-
making as a way to build a well informed and successful product and also as a way to create buy-in. Without buy-in
from the Scrum Team, a Product Owner can come off as a disconnected manager.
There are different ways for a Product Owner to involve Developers in decision making. For example, Developers can
provide technical insights and domain knowledge that the Product Owner might not have. This engagement
contributes to a Product Owner’s ability to make well-informed decisions, because Developers can help them
understand what is technically feasible and what is not. Additionally, different perspectives can lead to innovative
solutions that the Product Owner alone would not consider.
Key Takeaways
An effective Product Owner works with the rest of the Scrum Team to maximize the value of the product. This requires
a unique blend of skills and practices such as product management, an outcome-based mindset and facilitation
capability. These types of qualities allow a Product Owner to lead with the customer in mind and steer the Scrum Team
through product vision, strategy and goals while collaborating with stakeholders.
Product Owners need to continuously question their understanding of the market, the customer’s desired outcomes,
the product, where it is in its product lifecycle and also their goals. This exploration helps a Product Owner delve deeper
into understanding their product and continuously experiment and learn.
Communication, collaboration, delegation and strong decision-making are key skills for a Product Owner to satisfy
customer outcomes in a complex world. There are several techniques that a Product Owner can use to build clarity and
Based on Scrum.org (The home of Scrum) Página 13
The Professional Scrum Competency

maintain strong relationships with the team, stakeholders, customers and users in order to create more innovative
solutions and ultimately to maximize the value of the product.
As a Product Owner, you may also decide to delegate some decisions. For example, there may be decisions that you
know others are much more qualified to make, or where you feel that your input is not needed and would slow down
progress unnecessarily. If you choose to delegate decision authority to others, make that clear and respect it.
Regardless of how a decision is made for the product, a Product Owner is and will always be accountable for it.

1.3.2. Developer
The Developers are the Scrum Team members that create the product. Often people associate the word “developer”
with coder or programmer in software. But that is not the case, think of a developer as someone who helps to create
(develop) a valuable product for a customer, no matter what kind of product it is.
The Scrum Guide outlines the accountabilities of the Developers as:
• Creating a plan for the Sprint, the Sprint Backlog;
• Instilling quality by adhering to a Definition of Done;
• Adapting their plan each day toward the Sprint Goal; and,
• Holding each other accountable as professionals.

Characteristics of a Scrum Developer

Developers on a Scrum Team are committed to working collaboratively with other Scrum Team members to reach the
Scrum Team’s goals. Several characteristics embody a professional Scrum Developer, for example they:
• Are problem-solvers - Scrum is used to solve complex problems in which the solution is found through
exploration and adaptation.
• Live the Scrum Values - They live by the Scrum Values of courage, focus, commitment, respect and openness.
• Engage in continuous learning and improvement - They continually work to improve their soft-skills and the
dynamics of the team; while also learning new skills required to build a valuable product.
• Are dedicated to creating an excellent product - Eager to learn about the product, the product domain and the
needs of customers and stakeholders. Actively engage with stakeholders during the Sprint Review. Care deeply
about product quality beyond adhering to the Definition of Done.
• Support strong teamwork - Collaborate with other Scrum Team members and engage with stakeholders and
customers.
• Are adaptable - Respond well to change, such as the changing needs of customers and other stakeholders; and
the order of the Product Backlog items.

Common Myths about Developers

• Each Developer should have all the skills necessary to deliver the product
Why is this a myth? It’s true that each Scrum Team should have all the cross-functional skills necessary to deliver their
work. However, it’s not true that each Developer has to have all the skills necessary, or that each Developer has to
have the identical skills. Scrum Teams in total are cross-functional, but individual Developers may have different,
specialized skills. This myth may have derived from the fact that everyone involved in creating the product is called a
“Developer” and they do not have titles based on their specialty.
• “Developer” really means “Software Developer;” Scrum is only for software teams
Why is this a myth? Scrum is for creating solutions to complex problems. These problems include many domains other
than software development. Developers on a Scrum Team must have whatever development skills are necessary to
create the product in their domain.
• Developers have no role in deciding what they do. For example, they simply take the next PBI from the top
of the Sprint Backlog
Why is this a myth? One of the key tenets of agile practices in general, and Scrum in particular, is to put decision-
making in the hands of the people doing the work. Rather than being directed to do certain work, Scrum teams are

Based on Scrum.org (The home of Scrum) Página 14

The Professional Scrum Competency

self-managing. They must be given the space to determine how to do their work. This is true within the Scrum Team
as well. Developers must be empowered to determine whether they are the right person to work on the next backlog
item.
• Developers spend too much time in meetings
Why is this a myth? The Scrum Events are designed to provide regular opportunities for enacting the Scrum pillars of
inspection, adaptation and transparency. Having regular meetings, each with a specific outcome and time constraint,
reduces the number of ad hoc meetings that are necessary once someone realizes that a problem has occurred.

1.3.3. Scrum Master

A Scrum Master is the member of the Scrum Team that is accountable for the Scrum Team’s effectiveness and for
establishing Scrum as it is defined in the Scrum Guide.
They help the team improve their practices and effectiveness primarily by advancing the adoption of Scrum among
individuals, teams and organizations. However, Scrum Masters go beyond simply teaching others about the Scrum
framework. They help others understand Scrum theory, the purpose of each element of Scrum and why Scrum is
beneficial in helping the team deliver value. Understanding the “why” behind the elements of the Scrum framework
helps teams evolve from a mechanical use of Scrum to Professional Scrum.
Excellent Scrum Masters help their teams deliver value. They can help transform a team that struggles, into a team
that delivers value every Sprint.

Scrum Masters Support Their Teams and the Organization

Scrum Masters support their colleagues in many different ways. The Scrum Guide outlines some of the service that
Scrum Masters provide to others:
• The Scrum Master serves the Scrum Team in several ways, including:
o Coaching the team members in self-management and cross-functionality;
o Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
o Causing the removal of impediments to the Scrum Team’s progress; and,
o Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
• The Scrum Master serves the Product Owner in several ways, including:
o Helping find techniques for effective Product Goal definition and Product Backlog management;
o Helping the Scrum Team understand the need for clear and concise Product Backlog items;
o Helping establish empirical product planning for a complex environment; and,
o Facilitating stakeholder collaboration as requested or needed.
• The Scrum Master serves the organization in several ways, including:
o Leading, training, and coaching the organization in its Scrum adoption;
o Planning and advising Scrum implementations within the organization;
o Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
o Removing barriers between stakeholders and Scrum Teams.
They do this by using their knowledge and experience with Scrum, as well as a host of other skills and knowledge.

Common Myths about Scrum Masters

• The Scrum Master is the “Scrum Police.” They enforce Scrum rules.
Why is this a myth? There are very few “Scrum rules.” Scrum is designed to be a framework for helping teams execute
complex work. When Scrum Masters guide teams in understanding the principles of Scrum and purpose of its elements,
the benefits become clear. The Scrum Master is not an enforcer, they are a guide.
• The Scrum Master is the team’s manager.
Why is this a myth? There is no organizational hierarchy on a Scrum Team and the Scrum Master does not have
authority over team members. The Scrum Master does take a leadership role in guiding, coaching and mentoring the
Based on Scrum.org (The home of Scrum) Página 15
The Professional Scrum Competency

team; helping remove impediments that the team cannot remove themselves and creating a supportive environment
for team members.
• The Scrum Master’s primary focus is on team happiness and acting as a team cheerleader.
Why is this a myth? The Scrum Master’s primary focus is the team’s effectiveness and its ability to deliver value. They
identify team and organizational problems that impede a team’s ability to deliver value.
• The Scrum Master is a Project Manager.
Why is this a myth? Scrum Masters are not required to engage in traditional project management activities such as
day-to-day management of the project or managing the project’s scope, budget or deadline. They also do not oversee
individual team member’s work or tasks. The Scrum Master’s focus is on using Scrum and its principles to help the team
improve their effectiveness.
• The Scrum Master is the team’s admin. For example, they manage, schedule and take minutes in all meetings;
organize celebrations when milestones are achieved; and are the team’s JIRA administrator.
Why is this a myth? None of the items in the example above are elements of Scrum and they are not the responsibility
of anyone on the Scrum Team. If the Scrum Team decides that these activities would help them be successful, they
work together to decide who will be responsible for them.
• The Scrum Master must be technical.
Why is this a myth? The Developers on the team are the ones with the specialized knowledge of how to accomplish
the work. It MAY be beneficial for the Scrum Master to have an understanding of how Developers do their work in
order to serve them, but it is not required. The Scrum Master’s technical expertise is in Scrum and its complementary
techniques.
• The Scrum Master removes all impediments or blockers.
Why is this a myth? An impediment is simply a hindrance or obstruction to accomplishing something. We face this kind
of hindrance countless times each day whether it’s a locked door that should be unlocked, software that doesn’t work
as expected or a question without an immediate answer. Most impediments are resolved by the person that initially
faced it. Scrum Team members regularly face and resolve impediments. The Scrum Master steps in to help resolve
impediments when Scrum Team members are unable to do so on their own.
• The Scrum Master facilitates all Scrum Events
Why is this a myth? New teams often struggle with how to make their Scrum Events as fruitful as possible. Other teams
may have interpersonal dynamics that stymie consensus building. To help overcome these issues, Scrum Masters will
often build their facilitation skills (as well as their mentoring and coaching skills). However, this does not mean that the
Scrum Master is tasked with facilitating every meeting. Scrum Teams are most effective when they share these
responsibilities.
• Having Scrum Master certification is evidence that an individual will be an effective Scrum Master.
Why is this a myth? The first step in becoming a Scrum Master is having knowledge of the Scrum framework and how
to use it. It is not possible to be an effective Scrum Master without this knowledge. However, like any profession, being
truly effective at the job requires skill, practical experience and professional characteristics appropriate for the role.
Certification can provide evidence of a baseline of knowledge, but is unlikely to attest to an individual’s soft skills or
judgment.

1.4. Scrum Events

The Scrum events are key elements of the Scrum Framework. They provide regular opportunities for enacting the
Scrum pillars of Inspection, Adaptation and Transparency. In addition, they help teams keep aligned with the Sprint
and Product Goals, improve Developer productivity, remove impediments and reduce the need to schedule too many
additional meetings.
There are five Scrum events (the Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), each with
their own purpose, time constraints and participants.
Based on Scrum.org (The home of Scrum) Página 16
The Professional Scrum Competency

Purpose
While learning the details of each is very important for effective Scrum, at the highest level*, the purpose of each is
actually quite simple:
• Sprint - All work in Scrum is done in a series of short projects called Sprints. This enables rapid feedback loops.
• Sprint Planning - The Sprint starts with a planning session in which the Developers plan the work they intend to
do in the Sprint. This plan creates a shared understanding and alignment among the team.
• Daily Scrum - The Developers meet daily to inspect their progress toward the Sprint Goal, discuss any challenges
they’ve run into and tweak their plan for the next day as needed.
• Sprint Review - At the end of the Sprint, the Scrum Team meets with stakeholders to show what they have
accomplished and get feedback.
• Sprint Retrospective - Finally, the Scrum Team gets together to discuss how the Sprint went and if there are
things they could do differently and improve in the next Sprint.
* These descriptions are introductory, we strongly suggest a deeper understanding of each Event.

Time constraints
To help create discipline and focus, each of the Scrum events has a predefined time constraint, or timebox:
• The Sprint’s timebox is no greater than a month, though they are typically two weeks in duration.
• The Sprint Planning, Sprint Review and Sprint Retrospective are timeboxed to 8 hours, 4 hours and 3 hours,
respectively, for a one month Sprint. The team generally sets the maximum duration of these events to be less
when the Sprint is shorter than a month.
• The Daily Scrum is 15 minutes regardless of the length of the Sprint.
These timeboxes enable productive meetings that encourage relevant discussions while conversations not related to
the event’s purpose are discouraged. If the team is able to achieve the purpose of the time-boxed events (Sprint
Planning, Daily Scrum, Sprint Review and Sprint Retrospective) before the maximum time allotted is reached, they
should simply end the meeting.
When teams are unable to achieve the purpose of the event in the timebox, the team should investigate where they
can find opportunities to improve how they conduct their events.
Driving focus into the timeboxed events is a discipline that allows team members to spend less time in meetings, freeing
them to spend more time doing other work.

Participants
Each event has required participants from the Scrum Team. Not all Scrum Team members are required in all meetings.
And particularly for the Sprint Review, it’s necessary to invite individuals from outside the Scrum Team to provide
feedback and advice. Having the correct participants in each event ensures that the meetings are focused on their
purpose.

Scrum Events Quick Reference

The following is a quick summary of the timeboxed Scrum events. The Sprint is a container for all of these events and
is required to have a maximum duration of one month or less.
Event Inspection Adaptation Participants Timebox
Product Backlog, Product Goal, Sprint Backlog, 8 hours for a 1
Sprint Planning Scrum Team
Definition of Done Sprint Goal month Sprint
Daily Scrum Progress toward Sprint Goal Sprint Backlog Developers 15 minutes
Increment, Sprint, Product Backlog, Scrum Team, 4 hours for a 1
Sprint Review Product Backlog
Progress toward Product Goal Stakeholders month Sprint
Actionable improvements, 3 hours for a 1
Sprint Retrospective Sprint, Definition of Done Scrum Team
Definition of Done month Sprint

Based on Scrum.org (The home of Scrum) Página 17

The Professional Scrum Competency

Making Your Scrum Events More Effective

The purpose, timebox and participants of each of the Scrum events are well defined. However, we sometimes see
Scrum Teams fall into antipatterns that diminish their value.
Common antipatterns include:
• Events that consistently exceed their timebox - This can happen when participants lose sight of the purpose of
the event. Often teams deviate into additional conversations, rather than sticking to the purpose of the meeting
and scheduling another meeting to create solutions to issues uncovered during the event.
• Not all team members are “heard” - When team members do not feel comfortable providing their thoughts,
the team will not benefit from their skills and experience, and the value of the event is diminished.
• The Scrum Master drives the discussion and team members direct their comments to the Scrum Master - Each
of the Scrum events has a distinct purpose, they are all designed for the participants to work together to inspect
and adapt their progress toward the Product or Sprint Goal. The Scrum Master’s role is to help the team achieve
the purpose of each event.
• The Scrum events turn into status meetings - None of the events are status meetings, they are all intended to
help the team progress toward the Product or Sprint Goal.
• The team decides to eliminate some events because they feel that Scrum is meeting heavy - Every Scrum
event has a purpose and every team member is accountable for making each event productive. Continuous
improvement helps the team become more effective and purposeful over time. If the team finds that they are
conducting Sprint Planning, Sprint Reviews and Sprint Retrospectives too frequently and are receiving limited
value, it may be time to consider extending the length of the Sprint. This should be done with caution since a
basic tenet of Scrum is the frequent opportunities for inspection and adaptation.
• Team members wait until the next event instead of taking action right away - Scrum events are predetermined
opportunities for inspection and adaptation. However, if the team discovers the need for adaptation, they
should execute the change as soon as they practically can.
• The Scrum Master always facilitates the events - The Scrum Events can be facilitated by any team member, no
one has the official responsibility to be the meeting facilitator. That said, individuals who chose to be Scrum
Masters often chose to develop their facilitation skills and may be called upon to lead certain events.
• Scrum Team members refuse to call or attend non-Event meetings during the Sprint - Scrum teams will often
have to collaborate on problems and challenges that arise during their work. Having separate meetings, each
focused on a specific challenge, helps the team brainstorm and align on optimal solutions.
• The Developers only participate in the Daily Scrum and play a passive role in other events - Developers have
specialized skills, knowledge and experience that is needed for all Scrum Events to meet their purpose. Value is
always added through the Developers participation.

Tips for Strong Scrum Events

Breaking the antipatterns listed above help create strong and effective Scrum events. Consider the following tips:
• Make sure everyone has a voice
• Make sure everyone is aligned; encourage everyone to ask questions
• Make sure any follow up discussions are addressed
• Make sure information radiators are updated
• Make sure meeting stays true to its purpose
• Make sure meetings are valuable for all of the participants
• Make sure impediments are identified and addressed
• Make sure everything is transparent
• Make sure every team member has what they need

1.4.1. The Sprint

Unlike the other Scrum Events, the Sprint isn’t a meeting. Instead, it’s the container for all of the work that’s done by
a Scrum Team to achieve a Sprint Goal. The Daily Scrum, Sprint Planning, Sprint Review and Sprint Retrospective all fall
within the Sprint as well as Product Backlog Refinement.
Based on Scrum.org (The home of Scrum) Página 18
The Professional Scrum Competency

There is no work done in Scrum that is outside the Sprint and there are no gaps between Sprints. When one ends, the
next one immediately begins. Each Sprint starts with a planning meeting (Sprint Planning) and ends with a review of
the work completed during the Sprint (Sprint Review) and a review of how the Sprint went (Sprint Retrospective).
During the Sprint, the Developers meet daily (Daily Scrum) to review their progress toward their Sprint Goal.
Sprints should be no longer than one month in duration to support the Scrum tenet of rapid feedback loops.

Making Your Sprints More Effective

The purpose, timebox and participants of the Sprint are well defined. However, we’ve seen Scrum Teams fall into anti-
patterns that diminish their value.
Common antipatterns include:
• Continually rolling over work from one Sprint to the next - Teams that do not plan their work to fit into the
Sprint find themselves pushing work into the next Sprint.
• Frequently changing the Sprint length - As the product evolves, it may be appropriate to either lengthen or
shorten the Sprint. However, frequently changing the length of the Sprint may indicate that the team is going
back and forth between a desire to have less frequent meetings (Sprint Planning, Sprint Review and Sprint
Retrospective) and their realization that they need more frequent feedback from stakeholders.
• Specialized Sprints - Specialized Sprints (such as design, analysis or testing Sprints) generally indicate that
something is wrong in the team’s understanding of Scrum. For example:
o Some teams create a “Sprint 0” which is a Sprint before the formal start of the project. When a team
suggests having a Sprint 0, it may be because they feel they must create some artifacts (such as a Product
Backlog and the Definition of Done), or resolve some procedural or technical questions (such as what
tools to use in developing the product) before Sprinting. However, the essence of Scrum is to be able to
start with complex problems and to incrementally and iteratively solve them. There is no such thing as
“Sprint 0,” it’s just a “Sprint.”
o Some teams create a “hardening” Sprint which is dedicated to improving the quality of the product. If
the team feels it’s necessary to have a “hardening” Sprint, it’s often because they haven’t taken care in
creating, evolving and conforming to their Definition of Done. They typically take on too much work and
don’t have the time to create a high-quality result. There should not be “hardening” Sprints. Instead, in
early Sprints the Definition of Done may be less stringent and over the course of many Sprints, the
Definition of Done may become increasingly stringent, forcing later Sprints to have higher quality
expectations rather than abruptly creating a Sprint to rectify the quality issues.
• Running Sprints as mini-waterfall projects - The beginning of the Sprint is used for solution development. Near
the end of the Sprint timeframe, all of the work goes into a testing phrase.
Putting the entire Sprint Backlog in “doing” when the Sprint starts - Often, teams use a board to visualize the
Based on Scrum.org (The home of Scrum) Página 19
The Professional Scrum Competency

state of each Sprint Backlog item. At a minimum, these states are “To Do,” “In Progress,” “Blocked” or “Done.”
This antipattern results when Developers select the PBIs they intend to work on at the beginning of the Sprint
and put them all in the “doing/in progress” state.

Tips for Strong Sprints

Breaking the antipatterns listed above help create strong and effective Sprints. Consider the following tips:
• A two-week Sprint may be a good starting point for determining the Sprint length. If PBIs cannot be made small
enough to fit into a two-week Sprint or Sprint Goals cannot be defined so that they can be achieved in two
weeks, consider lengthening the Sprint. Shorter Sprints are beneficial because they provide opportunities for
more frequent feedback and adaptation.
• Keep the length of the Sprint as consistent as possible. Sometimes teams increase the length of the Sprint during
vacation periods, often to keep their “velocity” consistent across Sprints. However, velocity is a poor measure
of value creation. Teams should simply reduce the amount of work they forecast during periods of high
absenteeism.

1.4.2. Sprint Planning

Every Sprint starts with Sprint Planning where
the Scrum Team determines what they plan
to accomplish during the course of the Sprint.
During the meeting, the Scrum Team focuses
on:
• The value that can be created during
the Sprint
• Choosing which Product Backlog Items
will be addressed during the Sprint
• Planning the work required to
accomplish their goal
• Planning to create an Increment that
meets the Definition of Done
The Scrum Team makes this transparent by
creating a Sprint Backlog which includes the Sprint Goal, the selected Product Backlog Items and the Developers’ plan
for delivering the work.
Sprint Planning at a Glance

Event Inspection Adaptation Participants Timebox

Sprint Product Backlog, Product Goal, Sprint Backlog, Scrum 8 hours for a 1 month
Planning Definition of Done Sprint Goal Team Sprint

Conducting the Sprint Planning Event

Three topics are addressed during the course of the event:
• Why is this Sprint valuable?
• What can be Done during this Sprint?
• How will this work get done?
Sprint Planning is an event for the entire Scrum Team. They may invite people from outside the Scrum Team if they
feel their advice would be helpful. Individuals within the team have specific accountabilities during this Event:
Product Owner
• Makes sure that the attendees of the event have enough information about the most important Product Backlog
Items, including how they support the Product Goal.
Based on Scrum.org (The home of Scrum) Página 20
The Professional Scrum Competency

• Makes a proposal to the team about what they can develop that would be valuable for the stakeholders. The
team must be able to complete the work during the course of the Sprint. The PO shouldn’t propose how the
developers create this value.
Entire Scrum Team
• In a collaborative manner, the team crafts a Sprint Goal that indicates why this Sprint will bring value to the
stakeholders, including customers and users.
• This addresses topic one: “Why is this Sprint Valuable?”
Developers
• Select the items in the Product Backlog to address in the current Sprint. This addresses topic two: “What can be
done during this Sprint?”
• When Developers select the PBIs for the Sprint, they consider:
o The Product Backlog, including the Product Goal
o The Team’s assessment of their capacity, based on their past performance in previous Sprints
o The Definition of Done
o The current Increment, and
o Any process improvement suggestions that emerged during the team’s Sprint Retrospectives
• Create a plan for how to fulfill the PBIs. This addresses topic three: “How will this work get Done?”
Scrum Master
• Has specific accountabilities during the Sprint Planning event for helping the team fulfill the requirements of
the event. For example, the Scrum Master guides the team if they see that PBIs aren’t sufficiently defined, the
team doesn’t identify potential impediments, the Sprint Goal doesn’t support the Product Goal or the team has
selected an unattainable amount of work.
• Often the Scrum Master acts as the facilitator for this event, though this is not required. Facilitation of Sprint
Planning can be done by anyone at the event.

Making Your Sprint Planning Events More Effective

Antipatterns
The purpose, timebox and participants of Sprint Planning are well defined. However, we sometimes see Scrum Teams
fall into antipatterns that diminish their value.
Participants not fulfilling their accountabilities correctly:
• Unavailable Product Owner - If the Product Owner, or their delegate, doesn’t participate in Sprint Planning, the
Developers must step in and based on their understanding fulfill all the accountabilities of the Product Owner.
Unfortunately, they are unlikely to have all the information a Product Owner has that allows them to determine
what makes this Sprint and each Product Backlog Item more valuable relative to others on the Backlog. This
situation puts undue burden on the Developers and the stakeholders and may result in the wrong product being
developed.
• PBIs and Sprint Goal are selected by the Product Owner with no conversation about the value of the work -
In the course of implementing a PBI, Developers may make countless decisions and tradeoffs. Without
understanding the value of what they are creating, they are likely to make bad decisions.
• Only the team lead or a trusted, “core” team provides estimates. Scrum believes that the team is stronger
together and strong estimates take into consideration all team members’ viewpoints, knowledge and expertise.
• Pulling in too much work or Product Owner tells the Developers what work to pull into the Sprint - Developers
that do not determine what work can be accomplished during the Sprint are not fulfilling their accountabilities.
Backlog or Participants are Not Prepared for the Event:
• Lack of Product Backlog Refinement - Without adequate Refinement, the Developers make assumptions such
as: the value of each PBI; what the stakeholders are asking for and why they are asking for it; the acceptance
criteria for the PBI; and their ability to complete the work on each PBI in one Sprint. This puts the success of the
Sprint in jeopardy.
Based on Scrum.org (The home of Scrum) Página 21
The Professional Scrum Competency

• Ambiguous Requirements - If the PBIs do not have sufficient information for the Developers to understand
what is being requested, it is likely that the result of their work will not fulfill the stakeholders’ desires, wasting
everyone’s time.
• Having undone work at the end of a Sprint - Overestimating what work can be completed during the Sprint is
a sign that the PBIs aren’t sufficiently defined, the team has a poor assessment of their capacity or the Definition
of Done is overly restrictive for the current state of the product
• Work is broken down and estimated in this event - A strong Scrum Team regularly refines their backlog which
includes estimating and breaking down the work
• Sprint Planning takes too long - The more familiar the team is with the Backlog, through regular refinement
meetings and a defined definition of ready, the more efficient and effective these meetings are. Sprint Planning
meetings which are long, are often not well planned or facilitated.
Purpose of the Event not fulfilled:
• Erroneous Forecasts - Developers are asked to forecast what work can be done in a Sprint and Scrum Teams
are often asked to forecast when some part of the product will be available for use. Scrum Teams that do a poor
job of Sprint Planning usually are unable to create reliable forecasts.
• No Shared Commitment or Unclear Sprint Goal - Sprint Goals are designed to get the team focused around a
singular outcome. If the team isn’t committed to the same outcome, it’s likely that the Sprint Goal isn’t well
defined.
• Team talks more about velocity than value - Velocity is a measure of how much “stuff” is produced, regardless
of its value. Purpose of the Sprint is to create value, not execute a high volume of tasks.
• Testing is not complete by the end of the Sprint - If the testing that is required by the DoD is not complete at
the end of the Sprint, the work is not Done. The team is either ignoring their DoD or they are overestimating
the work they can execute.
• Teams don’t start work on the selected PBIs until all the work for the Sprint is defined. It is okay if there are
still unknowns during/after this event, the team starts with what they know and defines more of the unknowns
during the Sprint.

Tips for Strong Sprint Planning

Breaking the antipatterns listed above help create strong and effective Sprint Planning events. Consider the following
tips:
• Developers ask questions until it is clear how each PBI creates value or is useful to the customer
• Developers ask questions until they have a good sense of how they will implement the PBIs
• Scrum Teams collaborate on solving problems together
• Scrum Teams use metrics as criteria for selecting the amount of work selected for the Sprint
• Scrum Teams understand all the work needed to create an Increment that adheres to their Definition of Done
and uses this understanding to help them with capacity
• Scrum Teams devise strategies that enable multiple team members to focus on a PBI
• Scrum Teams focus on strategies that enable the lean principle of “just enough”
• Scrum Teams add improvement items to the Sprint that were uncovered by a previous Sprint Retrospective

Based on Scrum.org (The home of Scrum) Página 22

The Professional Scrum Competency

1.4.3. Daily Scrum

To keep work moving smoothly, the Developers get
together for 15 minutes every day to focus on the Sprint
Goal and to plan the upcoming day’s work. During the
Daily Scrum, they identify any issues they need help in
resolving, ask for help when they need it and adjust the
Sprint Backlog, if necessary.
The Daily Scrum ensures that all team members are
aligned, aware of any updates or changes and that the
team is making progress toward the Sprint Goal. A Daily
Scrum also promotes quick decision making and may
reduce the need to create additional, impromptu
meetings.

Daily Scrum at a Glance

Event Inspection Adaptation Participants Timebox

Daily Scrum Progress toward Sprint Goal Sprint Backlog Developers 15 minutes
It should be noted that the name of this event is not the Daily Stand-Up or Daily Huddle. Older versions of the Scrum
Guide referred to this meeting as the “Daily Stand-up.” However, it was changed to recognize that participants are not
required to stand and in fact, some participants may not be able to stand during the meeting.

Conducting the Daily Scrum

The Daily Scrum is timeboxed for 15 minutes. It’s recommended that the Daily Scrum take place at the same time and
place every day. By having this consistency, it becomes a habit that no one on the team has to think about.
It doesn’t matter what format the meeting takes, just as long as the meeting focuses on the progress toward the Sprint
Goal and results in an actionable plan. Typically, each Developer has the opportunity to bring issues they are having to
the surface and ask for help from their teammates. Depending on the nature of the issue, the Developers may not be
able to resolve them during the 15 minutes allotted to the meeting. Instead, they should plan to collaborate outside
the Daily Scrum.
During the Daily Scrum, the team often adjusts the Sprint Backlog by adding, removing, splitting and decomposing
Product Backlog Items (PBIs) and the tasks required to accomplish them.
Since neither the Product Owner or Scrum Master are required at this event, the Developers assume the responsibility
for conducting the meeting. Of course, if the PO and SM are actively working on the Sprint Backlog, they participate in
the Daily Scrum in their role as Developers.

Making Your Daily Scrums More Effective

While the purpose, timebox and participants of the Daily Scrum are well-defined, we sometimes see Scrum Teams
deviate away from its purpose. This can result in the Scrum Team falling into antipatterns that diminish the value of
the event. It is important for teams not to fall into these traps in order to ensure their work moves forward. The
following are common antipatterns which serve as examples of what NOT to do during your Daily Scrum.
Common antipatterns include:
• The Scrum Master runs the meeting as a status meeting, asking everyone to update on their progress on
tasks.
Why is this an antipattern to avoid? The Daily Scrum is a working meeting for the Developers to help ensure continued
progress in the work they are performing. By approaching the Daily Scrum as simply a status meeting, the true purpose
of the event will not be achieved.

Based on Scrum.org (The home of Scrum) Página 23

The Professional Scrum Competency

• Team members become focused on only their own work and forget to be on the lookout for opportunities
to help other team members.
Why is this an antipattern to avoid? The intent of the Daily Scrum meeting is to enable and promote collaboration
among the Developers.
• One or several Daily Scrum attendees habitually dominate the event.
Why is this an antipattern to avoid? Successful collaboration only works if every team member is able to participate in
the Daily Scrum meeting.
• Potential problems are not openly discussed by team members during the Daily Scrum and it sometimes
takes until the end of the Sprint to find out that one or more team members are struggling.
Why is this an antipattern to avoid? If the Daily Scrum is not a “safe” space for Developers to openly discuss their
challenges, they will go unresolved until it’s too late.
• Daily Scrum attendees only use the three question format to conduct the meeting. (What did you do
yesterday? What do you plan to do today? Do you have any blockers?)
Why is this an antipattern to avoid? While previous versions of the Scrum Guide suggested the three question format,
it was removed when it was recognized that it encouraged a mechanical approach to the Daily Scrum. Teams should
use whatever format works best for them to conduct the meeting to get the information they need.
• Developers only make changes to the Sprint Backlog at the Daily Scrum.
Why is this an antipattern to avoid? The Sprint Backlog can be changed as soon as a needed update is identified.
Information or actions should not be delayed due to waiting for an event to occur. The Daily Scrum can be used to help
update the Developers about recent changes that were made.
• The Product Owner and Scrum Master are forbidden from going to the Daily Scrum, even if their
participation would be useful.
Why is this an antipattern to avoid? The Daily Scrum is a meeting for the Developers, the Scrum Team members that
are actively working on items in the Sprint Backlog. If the Product Owner or Scrum Master are working on Backlog
items, then they participate in the Daily Scrum as Developers. Since there is no strict definition of how a Product Owner
or Scrum Master actively works on Backlog Items, they can participate in the Daily Scrum if their participation would
be beneficial.

Tips for Strong Daily Scrums:

Breaking the antipatterns listed above help create strong and effective Daily Scrums. Consider the following tips:
• Focus the meeting on the Sprint Goal and what is needed to achieve it
• Consider what value is being created toward the Sprint Goal. Create a safe space where everyone is comfortable
in participating and can be open about any struggles or impediments
• Foster an environment where team members are eager to help one another
• The Scrum Master’s assistance is not required at the Daily Scrum, the Developers should manage the meeting
and consistently meet its purpose

Based on Scrum.org (The home of Scrum) Página 24

The Professional Scrum Competency

1.4.4. Sprint Review

The Sprint Review is a working
meeting where the Scrum Team
presents their completed work to
their stakeholders and asks for
feedback and guidance. Together,
the Scrum Team and stakeholders
discuss the progress made toward
the Product Goal, any emerging
changes in the business or
technical climate and collaborate
on what to do next.

Sprint Review at a Glance

Event Inspection Adaptation Participants Timebox

Sprint Increment, Sprint, Product Backlog, Scrum Team, 4 hours for a 1
Product Backlog
Review Progress toward Product Goal Stakeholders month Sprint

Conducting the Sprint Review

The Sprint Review is a working, collaborative meeting for the Scrum Team and stakeholders to inspect progress and
adapt plans for the future. A common mistake teams make in conducting Sprint Reviews is for the Product Owner to
deliver a presentation of the work done during the Sprint to an audience of stakeholders. This eliminates one of the
most powerful tools in Scrum: frequent stakeholder feedback.
Instead, the entire Scrum Team should approach the Sprint Review as a way to collaborate with stakeholders on the
value they’ve created and how they should adapt their future plans in a way that will create even more value.
It’s important to plan the review in advance. For example:
• The team should decide what will be reviewed and discussed. Remember: only work that has met the Definition
of Done can be reviewed during the Sprint Review
• Based on what is being discussed at the review, someone on the team, often the Product Owner, will make
certain that the correct stakeholders are invited to the Sprint Review
• It’s good practice for the Scrum Team to identify the next important thing they want to learn and plan to get
feedback on that
• For every item to be discussed during the review, it’s best if a member of the team is assigned the job of leading
and focusing the discussion. Often, the person leading the discussion is the Developer (or Developers) who
worked on that item. It’s usually a bad idea for the Product Owner to lead the discussion on all the topics
• Anyone can be the facilitator of the Sprint Review; they can be a member of the Scrum Team, one of the
stakeholders, or someone not involved in the project at all. Often, the Product Owner facilitates the Sprint
Review since they are the stakeholder representatives for the Scrum Team during the Sprint and they are often
best at speaking the customer’s language
There are many different ways to conduct the Sprint Review itself and there are no prescribed formats. However, it
important that the purpose of the review is fulfilled.
The Scrum Team and stakeholders should:
• Inspect the outcome of the Sprint
• Discuss the progress toward the Product Goal
• Discuss any changes in the environment, such as changes in the marketplace, customer behavior and customer
Based on Scrum.org (The home of Scrum) Página 25
The Professional Scrum Competency

feedback
• Collaborate on what to do next. Consider what the next most valuable thing to do is and update the Product
Backlog

Making Your Sprint Reviews More Effective

The purpose, timebox and participants of the Sprint Review are well defined. However, we sometimes see Scrum Teams
fall into antipatterns that diminish their value.
Common antipatterns include:
• Sprint Review is a status meeting, demo or one-way presentation - Instead, It should be an opportunity for
the Product Owner & stakeholders to shape the future direction of the product.
• The product shown does not conform to the Definition of Done or is not integrated into the Increment -
Sometimes what is presented does not meet the team’s quality standards and only a portion of the product is
demonstrated. In either case, the stakeholders are put at a disadvantage when providing feedback.
• Team presents a list of the PBIs completed without showing the stakeholders the outcome of the PBIs or
having a discussion about the work
• The result of the Sprint is only shown in a presentation; the product/increment itself is not shown.
• The Sprint Review is conducted to have the Product Owner “accept” the work completed by the Developers
- It’s a myth that a successful Sprint Review is one where the Product Owner signs off on the work. The Product
Owner should work with the team throughout the Sprint and nothing should be a surprise at the Sprint Review.
• Developers do not attend - By missing the Sprint Review, the Developers miss the opportunity to receive
stakeholder feedback directly and will miss the context around any decisions about changes to the Product
Backlog and what to do next
• There are no actual users or customers among the stakeholders present - Often colleagues and management
will act as a proxy for the product’s customers. Finding customers that are well-suited to review a product while
it’s in development is not always an easy task, but it’s rewarding when it happens

Tips for Strong Sprint Reviews

Breaking the antipatterns listed above help create strong and effective Sprint Reviews. Consider the following tips:
• Make certain the correct stakeholders are invited to the Sprint Review and that they understand the purpose
of the Sprint Review and their role in it.
• Foster direct collaboration between stakeholders and team members.
• Facilitate the event so that stakeholders can be hands-on with the product.
• Ensure the language used is understood by all participants. Developers should resist the temptation to delve
too much into technical jargon
• Be clear on what was Done and not Done - The team gives a summary of what was Done in the Sprint, and
what was not done and moved back into the Product Backlog. Keep the Definition of Done visible to provide
transparency on this topic.
• Discuss how the Sprint went - The Developers share any issues they had during the Sprint and what actions
were taken to overcome them. Include an opportunity to discuss impediments that can’t be resolved by the
Scrum Team. By engaging stakeholders, the team can use the event to develop close partnerships with
stakeholders.
• Gather feedback - The Developers show stakeholders what was done in order to gather feedback on the value
of what was completed. This feedback helps the Developers and the Product Owner assess whether the
assumptions they made were right or wrong.
• Review current state of the Product Backlog - The Product Owner presents the current state of the backlog
including Product Backlog items that were not completed in the Sprint. Based on the feedback received from
the stakeholders, new opportunities may be identified, discussed together and potentially added to the backlog.
• Decide what to do next - The Scrum Team and Stakeholders collaborate on potential work for the next Sprint
based on learnings and results from the Sprint. New opportunities, risks, issues and market conditions are
discussed
• Adapt the Product Backlog based on the discussions during the Sprint Review
Based on Scrum.org (The home of Scrum) Página 26
The Professional Scrum Competency

• Review the Product Vision, Key Value Drivers, Product Goal and Sprint Goal
• Ask Stakeholders to rate the Sprint Review to learn where improvements can be made

1.4.5. Sprint Retrospective

The Sprint Retrospective is the last event in the Sprint and is the time set aside for the Scrum Team to find ways to
improve their effectiveness and how they work as a team. Unlike other Scrum Events where the focus is on inspecting
and adapting ways to improve the product, the Sprint
Retrospective is a place for the Scrum Team to inspect and
adapt their working practices.
The team typically discusses:
• How well the team members interact and
communicate
• Any impediments they’ve encountered
• How well impediments were removed
• If the Definition of Done still serves them as written, or
if it needs to be updated
• If there are any improvements to how the team works
that can be implemented in future Sprints
Sprint Retrospective at a Glance

Event Inspection Adaptation Participants Timebox

Sprint Sprint, Definition of Actionable improvements, 3 hours for a 1 month
Scrum Team
Retrospective Done Definition of Done Sprint

Conducting the Sprint Retrospective

The Sprint Retrospective is an event for the entire Scrum Team to discuss what went well, what problems were
encountered and how those problems were, or were not, solved. During the meeting, the team identifies changes to
the way they work to help improve their effectiveness. In order to not lose track of these suggestions, it’s good practice
to make them visible by adding them to the Sprint Backlog for the next Sprint.
It’s often the case that the Scrum Master assumes responsibility for facilitating the Sprint Retrospective, but it’s
certainly not required. In fact, in order to keep all members of the team engaged during Sprint Retrospectives, it’s good
practice for them to take turns acting as the facilitator for this event.
A simple way to conduct the Sprint Retrospective is to:
• Set up a whiteboard with three sections:
o What went well?
o What didn’t go well?
o What could be improved?
• Ask each Scrum Team member to put a “sticky” note in the relevant sections
• Discuss each item
• Create a list of improvements that the team agrees should be undertaken
• Have the team order this list and pick the top 1 or 2 to work on in the next Sprint
However, there are many more creative ways to facilitate the Sprint Retrospective and we encourage team members
to learn some of these techniques and to volunteer to facilitate their team’s Retrospectives.

Making Your Sprint Retrospectives More Effective

The purpose, timebox and participants of the Sprint Retrospective are well defined. However, Scrum Teams sometimes
fall into antipatterns that diminish their value and waste everyone’s time.

Based on Scrum.org (The home of Scrum) Página 27

The Professional Scrum Competency

Common antipatterns include:

• Scrum Team members do not actively participate - When Scrum Team members are passive during a Sprint
Retrospective, the Scrum Master will often step in and pull information from the team, or will come up with
their own list of areas for improvement
• Issues are not raised during the Retrospective, but team members grumble about them outside the meeting
• Participants do not recall issues that came up during the Sprint so the issues are not raised during the
Retrospective
• The team becomes complacent and says that there is nothing they can improve
• Lack of honesty and communication - Often because they’d like to minimize conflict or because there is a lack
of trust on the team
• Recurring items, nothing changes - When the same impediments or ineffective team interactions are identified
in multiple Sprint Retrospectives, it’s an indicator that nothing is being done to rectify the problems or make
improvements
• Team focuses on items they cannot improve - Some teams spend too much time focused on items that are
outside of the team’s domain and influence
• Participants are told they are “being negative” when they identify items that need to be improved - This
generally results in participants being unwilling to make further observations
• The Sprint Retrospective turns into a “blame game” where the focus is on people rather than the process
• The team is not comfortable with the Product Owner attending the Sprint Retrospective - Often this happens
when the Product Owner acts as though they are a manager of the team, rather than as a team member
• There is no plan for conducting or facilitating the Sprint Retrospective or it’s conducted in the same way each
time - Participants may find the Retrospective boring, stale, unfocused and a waste of time if they either don’t
plan how they will run the Retrospective or they mechanically follow a three question format:
o What went well?
o What was a challenge?
o What could be improved?

Tips for Strong Sprint Retrospective

Breaking the antipatterns listed above help create strong and effective Sprint Retrospectives. Consider the following
tips:
• Make certain that everyone participates and has a voice. Be cognizant of the communications differences
among team members; some may be introverts and others may be extroverts. Also, if a team member acts in
an unruly way, address the issue right away.
• Encourage an environment where team members are eager to improve their working environment.
• Encourage strong psychological safety and a culture of radical transparency and openness where every team
member can be honest about issues in the team’s working practices, even if they may create some (healthy)
conflict.
• Make certain that items identified during the Retrospective are those that will actually improve the team’s
working processes or environment.
• Act on the items identified and make certain that the entire team knows how the items were resolved.
• If the team identifies an overwhelming number of improvement items, consider having the team prioritize the
improvements and then improve on 1-2 each Sprint.
• Make certain that the Scrum Team has a clear understanding of what issues are not within their circle of
influence and identify issues that are being resolved by others outside the team. Be transparent about the
resolution status of those issues.
• Ask Scrum Team members to keep a list of issues that occurred during the Sprint so that they can be raised
during the Retrospective.
• Don’t forget that the state of the Retrospective itself should be part of the Retrospective. Identify ways to
improve the Retrospective.
• Identify who will facilitate the Retrospective and encourage the use of varying facilitation techniques.

Based on Scrum.org (The home of Scrum) Página 28

The Professional Scrum Competency

1.5. The Scrum Artifacts

In archeology, an artifact is an object of cultural significance. In medicine, artifacts are something not normally present,
or unexpected. In Scrum, our use of the word “artifact” is closer to the way software developers use it: important
information needed during the development of a product.
Scrum has three artifacts:
• Product Backlog
• Sprint Backlog
• Increment
Each artifact contains information important to a Scrum Team and their stakeholders. This information details the
product being developed, the actions needed to produce it and other information relevant to create value.
Each artifact has a “commitment” which describes the goal for the artifact. Commitments provide clear objectives
against which progress can be measured.
Artifacts and their commitments are designed to maximize transparency of this key information so that everyone
inspecting them has the same understanding and a basis for adaptation.
The artifacts and their commitments are:

Artifact Commitment
Product Backlog Product Goal
Sprint Backlog Sprint Goal
Increment Definition of Done

1.5.1. Product Backlog

The Product Backlog’s purpose is to represent all of the work the Scrum Team knows it needs to do in order to deliver
the product. Teams can use the Product Backlog to make decisions about what they should do next.
The Product Backlog consists of:
• Product Backlog items (PBIs) - each of which represents something that needs to be done.
• A Product Goal - that describes the Scrum Team’s current long-term objective for the product.
Product Backlogs are a single, transparent way to find the Scrum Team’s current knowledge of all work that must be
done. They are kept as an ordered list.
• Single: There should be only one Product Backlog per product. This means that there are no separate backlogs
for different types of PBIs, for example no backlog for defect reports or for UX work. Everything lives in the
same Product Backlog. Additionally, if multiple Scrum Teams are working on the same product, they use the
same backlog.
• Transparent: it should be easily accessible and used to drive a shared understanding of the PBIs among the
Scrum Team and stakeholders.
• Current: The Product Backlog is “emergent” meaning that it grows, shrinks and evolves over time. It is not a
static artifact, it is updated frequently based on information uncovered during development as well as from
stakeholders, customers and the market.
• Ordered: The order of the PBIs is decided by the Product Owner. The order may be based on factors such as
business value, risk, return on investment or dependencies.

Product Backlog Items

Each PBI represents work that the team intends to do. There is no rule about what information each PBI should contain,
how it’s written or formatted, the granularity of each PBI or the tools used to maintain the Product Backlog.
PBIs are written in the form that serves the team best. For example, they can be written as user stories, hypotheses,

Based on Scrum.org (The home of Scrum) Página 29

The Professional Scrum Competency

defect reports or whatever other format helps the team. They generally contain a title, description, a size estimation
and an estimation of value.
PBIs may describe new functionality; improvements to existing functionality; a problem with the current product that
must be addressed; non-functional requirements for the product (such as reliability standards); new ideas;
experiments, etc. They can be anything, as long as they help the team understand what it needs to do.
PBIs are written at the right level of detail needed by the Developers at the time. When first created, they may be very
high-level and may only act as a placeholder. Over time, as more information is uncovered or as they become more
important to address, they are improved and refined. Eventually they will have sufficient information for Developers
to take action.
The Product Owner is accountable for creating PBIs. They can delegate the responsibility so that anyone on the team
may add PBIs to the backlog.
The size estimations are done by the Developers because they are the only ones in a position to estimate how much
work each PBI involves. There are many ways to estimate the size of PBIs:
• Absolute - often time-based; for example, “This PBI will take 9 hours of work”.
• Relative - uses a scale that lets developers estimate the size of the PBIs relative to each other; for example,
story points or t-shirt sizing.
• Flow metrics - based on the team’s historical data such as throughput
• Right sizing - identifies items that are small enough to be completed within one single Sprint, often using a flow-
based approach; for example, Developers discuss if they can complete a PBI according to their Definition of
Done comfortably within one Sprint, otherwise they should break down the PBI

Product Goal
The Product Goal describes the future state of the product. It’s a “commitment” for the Product Backlog meaning that
it is meant to provide focus for the Scrum Team and a target against which progress can be measured.
There is no specific format for the Product Goal or indication of how long the planning horizon is for a Product Goal.
What Scrum does specify is that there is only one Product Goal at a time and it’s either achieved or abandoned before
starting the next one.
To understand this more fully, we have to consider the broader context in which Scrum and the
Product Goal live. Organizations typically choose to create or maintain products based on their business strategy. This
strategy often leads to the creation of a very high-level product vision. This is often an aspirational vision of what the
product could be and customer problems it could solve. This kind of vision can be very motivating for teams, however
it can sometimes be difficult for Scrum Team members to comprehend how they can contribute to this vision.
To help with this, the Product Goal is a concrete, actionable, measurable objective. It serves as a bridge between the
product vision and the Sprint Goals. It’s a step toward the vision that is well enough defined that the team can use it
to plan and evaluate their progress toward that vision.
The Product Goal provides context for the Product Backlog. Scrum Teams create Product Backlog items that will fulfill
the Product Goal and use Sprints and Sprint Goals to bring them incrementally closer to achieving the goal. Once
achieved, the team formulates a new Product Goal that will bring them closer to realizing the product vision.
Sometimes new information comes to the surface resulting in the team abandoning or reformulating their Product
Goal. This isn’t a failure, but a natural consequence of incremental and experimental development.

Product Backlog Refinement

Product Backlog items (PBI) evolve over time. They start as vague ideas and are improved as more information is
uncovered. Eventually they are well enough defined that they can be brought onto a Sprint Backlog.
The activity of continually improving PBIs until they are ready to be worked on is called “refinement.” Most Scrum
Teams refine during working sessions in which they have focused discussions about the items in the Product Backlog.
During these sessions they create a shared understanding of the goals for each item and discuss the order of the items
in the backlog.
Based on Scrum.org (The home of Scrum) Página 30
The Professional Scrum Competency

Refinement of the Product Backlog may happen many times during the Sprint. In some Sprints, the PBIs at the top of
the backlog may be sufficiently refined and refinement may not be needed at all. Therefore, Product Backlog
refinement is not a prescribed event in Scrum.
However, in order to create greater clarity and a shared understanding, it is good practice to have the Product Owner,
Developers and appropriate stakeholders engage in refinement discussions on a regular basis. Self-managing teams
determine how often refinement should happen, as well as who should attend each session.

1.5.2. Sprint Backlog

The Sprint Backlog represents what the Developers plan to accomplish during the Sprint.
The Sprint Backlog is created by the Developers
during the Sprint Planning Event. It describes the
why, what and how of the Sprint. It consists of:
• The Sprint Goal which describes the
objective for the Sprint.
Why are we doing this Sprint?
• A set of Product Backlog items (PBIs)
selected for the Sprint.
Which PBIs will be addressed in this Sprint?
• An actionable plan for how the team will
deliver the work and achieve the Sprint
Goal.
How will we achieve our Sprint Goal?
Sprint Backlogs are highly-visible and located
where anyone on the Scrum Team can see them. They are also continually updated throughout the Sprint to provide a
real-time picture of the work the Developers plan to accomplish.
The selected set of PBIs and the plan to achieve them evolve over the course of the Sprint, often during the Daily Scrum.
In contrast, the Sprint Goal remains the same for the entire Sprint. In rare circumstances, information is uncovered
that makes the Sprint Goal obsolete. In this case, the Product Owner may decide to cancel the Sprint.

The Sprint Goal

The Sprint Goal is a “commitment” for the Sprint Backlog meaning that it is meant to provide focus for the Scrum Team
and a target against which progress can be measured.
The Sprint Goal provides the objective for the Sprint and frames many of the events during the Sprint:
• Objective: The Sprint Goal should indicate why this Sprint will bring value to the stakeholders, including
customers and users.
• Sprint Planning:
o The Sprint Goal is created by the entire Scrum Team during Sprint Planning. Ideally, all of the Developers
on the Scrum Team will work on items that support the Sprint Goal. In this way, the Sprint Goal provides
a unifying force to the Sprint and to the team.
o The PBIs selected for the Sprint during Sprint Planning are intended to help the team reach the Sprint
Goal.
• Daily Scrum:
o During the Daily Scrum, the Developers assess whether they are making progress toward the Sprint Goal
and adapt their plans accordingly. They may adjust the scope of the work they intend to do, but they
must not make changes to the Sprint Goal.
• Sprint Review:
o The Scrum Team and stakeholders discuss the progress made toward the Product Goal.
Based on Scrum.org (The home of Scrum) Página 31
The Professional Scrum Competency

Using Sprint Backlogs Effectively

Having a well-managed and effective Sprint Backlog helps everyone understand what will and will not be accomplished
during the Sprint.
Building an effective Sprint Backlog starts during the Sprint Planning event. At the end of the event:
• The Scrum Team has defined the Sprint Goal and the Developers commit to achieving it
• The Developers have selected a set of Product Backlog Items that they forecast will be Done during the Sprint
• There should be only one Sprint Backlog; there should be no separate backlog for enhancements, defects or
other tasks
• The Sprint Backlog should have one or two Sprint Retrospective improvement items that the team would like
to work on during the Sprint
• The Sprint Backlog should include an actionable plan for how the team will deliver the work and achieve the
Sprint Goal
o One way to create this plan is to decompose selected PBIs into multiple units of work that allow progress
on the PBIs to be transparent
o Ideally, the Developers do this work together. This conversation helps uncover dependencies and
impediments in the work and drives greater alignment and understanding among team members
There is no specific format for the Sprint Backlog.
However, many teams create a Scrum Board which
helps them visualize progress on the PBIs by
indicating the state of each item on the Sprint
Backlog. These states are often “To Do,” “In
Progress,” and “Done.”
During the Daily Scrum, the team focuses on the
progress being made toward the Sprint Goal and
they discuss adjustments to the Sprint Backlog.
These adjustments include adding, removing,
splitting and decomposing Product Backlog Items
(PBIs) and the tasks required to accomplish them.
These adjustments are often made after the Daily
Scrum concludes.

Sprint Backlog Antipatterns

Understanding how to create and maintain an effective Sprint Backlog is important since it guides the work the
Developers undertake during the Sprint. However, we often see Scrum Teams fall into unfortunate antipatterns. It is
important for teams not to fall into these traps. The following are common antipatterns which serve as examples of
what NOT to do.

Antipatterns around the Sprint Goal

• No Sprint Goal
Why is this an antipattern to avoid? The Sprint Goal is an important aspect of Scrum. It should not be omitted.
• The Sprint Goal is simply a description of the selected PBIs - Some teams select the PBIs they plan to work on
and then attempt to craft a Sprint Goal that ties them all together, even if there really is no common thread.
Why is this an antipattern to avoid? Creating the Sprint Goal this way minimizes the value and importance of the Sprint
Goal.The Sprint Goal is not a summary or label for the PBIs selected. Instead, the PBIs selected should support the
Sprint Goal. A Sprint Goal is meant to be an overarching objective that creates cohesion for the work in the Sprint.
• The Sprint Goal changes during the Sprint
Why is this an antipattern to avoid? Developers adapt or change the way they attain the goal, but the Sprint Goal must
remain the same throughout the Sprint.

Based on Scrum.org (The home of Scrum) Página 32

The Professional Scrum Competency

Antipatterns around the PBIs and work selected

• Sprint Backlog isn’t updated as the Sprint progresses - This antipattern arises when teams select a set of PBIs
during Sprint Planning and don’t modify them once the Sprint begins. These teams either don’t adapt the list
of PBIs (by adding or removing PBIs) or don’t adapt the content of the PBI once it’s put on the Sprint Backlog.
Why is this an antipattern to avoid? The Sprint Backlog should be a real-time reflection of the progress toward the
Sprint Goal and the PBIs on the Sprint Backlog should evolve as the team learns more about how to satisfy the Sprint
Goal
• Sprint Backlog is only updated during the Daily Scrum
Why is this an antipattern to avoid? The Sprint Backlog is updated as a result of the conversations during the Daily
Scrum. However Developers should also update the backlog to reflect the work in progress as they are doing the work.
• The Sprint Backlog never includes an improvement item
Why is this an antipattern to avoid? During the Retrospective, teams should identify a few changes in the way they do
their work that will improve their effectiveness. These should be added to the Sprint Backlog when practical.
• Stakeholders adding new PBIs to the Sprint Backlog
Why is this an antipattern to avoid? The Sprint Backlog should be visible to the stakeholders, however they should not
have the latitude to modify it. Should emergencies arise, the stakeholders should address them with the Product Owner
who will make the judgment about how to handle the issue.
• Sprint Backlog is only updated by the Scrum Master or Product Owner
Why is this an antipattern to avoid? The Sprint Backlog is managed by the Developers. The Developers may ask the
Scrum Master or Product Owner to assist in Sprint Backlog management if it helps the Developers be more effective.
• There is no ability to determine how much work remains
Why is this an antipattern to avoid? The Sprint Backlog should reflect the current state of all the work for the Sprint. It
should indicate the work completed, the work underway and the work that remains.
• Laser-like focus on moving PBIs on the Sprint Backlog rather than holding conversations about the work
Why is this an antipattern to avoid? The Sprint Backlog is an artifact that helps the Developers guide their work. Moving
PBIs on the Sprint Backlog should be a result of doing the work, not the focus of the Sprint.

Antipatterns around Sprint Backlog visualization

• Sprint Backlog isn’t public
Why is this an antipattern to avoid? The backlog should be visible by the entire team and stakeholders.
• Having the Sprint Backlog obscured in a tool
Why is this an antipattern to avoid? Poorly configured tools sometimes create process overhead that make it more
difficult to easily understand the Sprint Backlog. Tools for managing the backlog should support its transparency, not
hinder it.

Team and organizational dysfunctions

• Commitment is to PBIs planned and not the Sprint Goal
Why is this an antipattern to avoid? The purpose of the Sprint is to achieve the Sprint Goal. The PBIs selected are a
hypothesis of the work needed to achieve that goal.
• Management owns the Sprint Backlog rather than the Developers owning it
Why is this an antipattern to avoid? This antipattern often includes other dysfunctions such as:
o Micromanagement of the team, rather than Scrum Team self-management
o Sprint Backlog doesn’t reflect actual progress or impediments. A lack of trust between management and
the Developers can create an atmosphere where a more optimistic view of the work is presented instead
of the truth. Instead, the Sprint Backlog should be an accurate reflection of the success and challenges

Based on Scrum.org (The home of Scrum) Página 33

The Professional Scrum Competency

that the Developers face during the Sprint.

o Pressure to focus on completing the PBIs, rather than focusing on attaining the Sprint Goal
o Focus on Sprint Metrics such as output and velocity, rather than a focus on customer outcomes
• Only the work of Developers in the Sprint Backlog
Why is this an antipattern to avoid? Often, Product Owner and Scrum Master have work that must be done during the
Sprint. Their work should also be reflected on the Sprint Backlog.

1.5.3. The Increment

The Increment is the latest version of the product that conforms to the Definition of Done.
Scrum Teams create products. These products can be a physical product for sale, a service or even something abstract.
They can be:
• products for sale to the public, such as a mobile application or hair shaver
• products delivered to people within the Scrum Team’s organization, such as an internal software application,
marketing collateral or the results of scientific research
During each Sprint, the Developers work toward the current Product Goal by implementing Product Backlog items
(PBIs) and integrating their individual work together. The team and its stakeholders know that the product Increment
is Done, or usable, when it conforms to their defined quality standards. These quality standards are known as the
Definition of Done (DoD).
As soon as the first Product Backlog item meets the DoD, the Scrum Team has created the first product Increment.
If a developer adds something to the product that makes it no longer conform to the DoD, that version of the product
is not the Increment. At that point, the Increment is the last version of the product that did conform to the DoD. There
is only one Increment at a time.
The entire Scrum Team works to deliver at least one Done Increment each Sprint. During the Sprint Review, the Scrum
Team and stakeholders review what was accomplished during the Sprint. The latest Increment should be one of the
things that is inspected.
Producing an Increment every Sprint is important because it provides the Scrum Team an opportunity to get feedback,
test hypotheses and change course, if necessary.

The Definition of Done

The Definition of Done (DOD) is the artifact commitment for the Increment. As is the case for the other artifact
commitments in Scrum, it is meant to provide focus for the Scrum Team and a target against which progress can be
measured.
The Definition of Done describes the quality standards for the Increment to be considered “Done” and in a usable state
for it to be effectively inspected during the Sprint Review. Knowing that the Increment conforms to the DOD helps
stakeholders understand the completeness of the work they are reviewing.

Myths about the Increment

There are many myths that surround the understanding of the Increment:
• The Increment is released to the stakeholders after it is reviewed at the Sprint Review
Why is this a myth? The Sprint Review is an opportunity for the Scrum Team to get feedback and guidance from the
stakeholders. It is not a gate for delivering an Increment to them.
• Only one Increment is delivered to the stakeholders per Sprint
Why is this a myth? Several Increments can be delivered to the stakeholders (including customers and users) during
the course of the Sprint.
• The Increments can be everyone’s individual work. They don’t have to be integrated together.
Why is this a myth? When individual Developers have completed a PBI, it is not part of the Increment until it is
integrated into one Increment that conforms to the Definition of Done. There is only one Increment at any given time.
Based on Scrum.org (The home of Scrum) Página 34
The Professional Scrum Competency

• There is something called an undone Increment.

Why is this a myth? The Increment must conform to the Definition of Done. If it doesn’t, it’s not considered an
Increment.
• Because the Increment must be “usable,” it must provide all of the functionality anticipated in the final
product.
Why is this a myth? An Increment doesn’t have to be a fully fleshed out product, just usable enough that stakeholders
can provide feedback. For the Increment to be considered usable for this purpose, it has to conform to the Definition
of Done (DOD).
• An Increment is always software.
Why is this a myth? It’s true that Scrum was created as a better way of developing software. However, Scrum is now
used in various industries to build products and solve complex problems. The Increment is whatever shape the
“product” is. For example, for scientific research, the Increment may be the emerging research report.

1.6. Definition of Done

The “Definition of Done” (DoD) describes the quality standards for the Increment to be considered “done” and in a
state that it can be effectively inspected. It provides to the Scrum Team and organization a common understanding of
the completeness of the Increment. Without this crystal clarity, it’s not possible for stakeholders to provide informed
and reliable feedback.
Starting in the 2020 Scrum Guide, the Definition of Done is referred to as a commitment contained in the Increment.
It is the commitment the Developers make regarding the quality of the Increment.

1.6.1. Characteristics of the Definition of Done

Every Scrum Team must have and conform to their DoD. It must be consistently used, easily referenced and have
appropriate criteria.
It’s not possible for us to prescribe precisely what criteria should be in your team’s DoD. It really depends on your
product, stage of product development and team capabilities. But we can give you some tips on what to look for and
ways to avoid problems that are frequently encountered.

Characteristics of a good DoD

A DoD generally includes items that ensure both business and technical product readiness. It describes product
qualities that make it valuable to your customer and practices that the developers know they should use in order to
create a high quality result. The specific items on the DoD are highly dependent on the type of product that the team
is developing.

Generic examples
Examples of Product Qualities:
• Compliant with usability and accessibility standards
• Compliant with design or style guides
• Made available or accessible by users/customers
• Compliant with applicable laws and regulations
• User documentation is complete
Examples of Development Practices:
• Quality testing procedures have been followed
• Work/Increment from multiple teams properly integrated

Industry-specific examples
For a software product, the DoD may include items such as:
Based on Scrum.org (The home of Scrum) Página 35
The Professional Scrum Competency

• Integrated into a clean build

• Promoted to a higher level environment
• Automated regression tests passed
• Feature level functional tests passed
• Non-Functional requirements met
• Meets compliance requirements
• Functionality documented in necessary user documentation.
For a marketing brochure, the DoD may include items such as:
• Compliant with corporate branding guide
• Compliant with grammar and style guide
• Graphics and trademark check performed
• Copy edit review
• Print-ready PDF created
• Old brochure digital assets and files replaced
• Old brochures removed

DoD Characteristics to Avoid

Anything that inhibits the DoD from being consistently used should be avoided. Often when teams disregard their DoD
it’s often because they either couldn’t find the DoD or because it wasn’t crafted well enough, making it feel irrelevant
to the team members.
Avoid the following situations:
• DoD is not easily found - We often hear of Developers indicating that they simply couldn’t find the DoD.
• The standards in the DoD are set too low - if the DoD is too lax, it not only doesn’t serve its intended purpose,
but it will feel inconsequential and easily ignored
• The standards in the DoD are unachievable - many conditions can contribute to an overly ambitious set of
criteria. For example, the quality standards may be set too high for the stage of the product development, or
items cannot be completed due to infrastructure constraints or other reasons
• The DoD creates a lot of administrative overhead - for example, the DoD is simply too long and contains items
that aren’t truly necessary
• The team doesn’t buy in or agree with the DoD - often this is because it was imposed on them without their
participation

1.6.2. Frequently Asked Questions about being Done

Getting to Done and the Definition of Done is critically important aspect of Scrum. Yet there are many myths and
misconceptions. The following are a few of the questions we most frequently hear about these concepts.
• What does it mean to be Done in Scrum?
In normal conversation, when we talk about something being done, we mean that it was completed successfully. When
Scrum practitioners speak about their work being “Done”, they mean that the Increment has achieved a level of quality
that makes it suitable for review and feedback from stakeholders. This is the same level of quality that is needed for
the product to be released to its customers.
• What is “undone” work?
Work on the Increment that hasn’t achieved the quality standards outlined in the Definition of Done is work that is not
yet “done.” Work that is not yet done is also known as “undone” work.
• Why is getting to “Done” so important?
A key tenet of Scrum is the use of rapid feedback loops. Yet in order to provide good feedback, team members and
stakeholders must be confident of the state of the product. Reviewing something that’s incomplete forces the reviewer
to make assumptions or guesses about what the product would be like if it were actually complete. Feedback is easier
to provide, more informed, and more reliable when the work is finished.
Based on Scrum.org (The home of Scrum) Página 36
The Professional Scrum Competency

• Is it Okay to Show Stakeholders work that isn’t Done?

It is a myth that Scrum Teams should only show Done work to their stakeholders. It’s probably an extreme response to
the fact that showing a stakeholder something that's only partially finished makes it a bit harder for the stakeholder to
give the best feedback they can.
What’s true is that frequent feedback from stakeholders is a hallmark of Scrum. So it’s completely natural for Scrum
Teams to ask for feedback or input before the work is complete. Understanding that the Definition of Done has not yet
been met helps set the stakeholder’s expectations on what is being discussed.
• Is the Sprint Review the place to ask for Stakeholder feedback on work that isn’t Done?
No, work that doesn’t meet the DoD should not be presented at the Sprint Review. Stakeholders must be confident
that the work they see during the Sprint Review meets the expected quality standards.
However, the Sprint Review seems like a very convenient venue to get feedback on undone work. Our suggestion is to
wait until the Sprint Review itself is complete, pause, declare the Sprint Review to be concluded and set the context
that the Scrum Team is looking for feedback and guidance on work that is not Done.
• Who creates the Definition of Done?
The answer to this question depends on whether the organization has already created a DoD for their products. If that’s
the case, the Developers on your Scrum Team are required to conform to that DoD at a minimum. Your team is always
welcome to add more stringent standards, but you may not make them more lax.
If no organizational DoD exists, the Scrum Team is obligated to create one for their product so that the Scrum Team
and stakeholders are all clear on what it means for the Increment to be done. This should be one of the first things a
Scrum Team does together.
If multiple Scrum Teams are working together on the same product, they must integrate their Increments together and
the result must comply with the same Definition of Done.
• Can the Definition of Done change?
Yes! It’s normal for the DoD to be refined as the team matures and the team’s understanding of the product and how
to build it improves. When the team begins work on the complex problem put in front of them, they may not know
how to articulate all the quality characteristics needed for the final product. But they’ll start with what they know and
will continue to refine the DoD over time.
• When is the Definition of Done changed?
Since the Sprint Retrospective is time set aside for planning ways to improve the team’s effectiveness, it’s the most
appropriate place to discuss and refine the DoD. However, Scrum practitioners don’t wait for a Scrum Event to take
necessary action; if the team sees a need to refine the DoD, they should do it whenever it’s practical to do so.
• What if the Scrum Team ignores the DoD or doesn’t get to Done?
Getting to Done is a necessary aspect of delivering a valuable product and is a key tenet of Scrum. When Scrum Teams
don’t create Increments that meet the necessary quality standards, they are increasing risk and decreasing
predictability.
When Scrum Teams don’t get to Done:
o stakeholders cannot rely on the quality of the product, creating friction and uncertainty where it
shouldn’t exist
o it’s unclear how far the work is from being done, so it becomes difficult to make estimates or plan the
work that can be achieved in a Sprint
o they are prioritizing speedy delivery over high quality which often results in work that will have to be
redone in the future
• What is the difference between the DoD and Acceptance Criteria?
The use of “acceptance criteria” is not technically part of Scrum, but is a valuable complementary practice. The
Definition of Done describes characteristics of the Increment and whether it is “done.” In contrast, “acceptance
criteria” are generally characteristics of a Product Backlog Item (PBI) and describe whether the PBI is done.
Based on Scrum.org (The home of Scrum) Página 37
The Professional Scrum Competency

You may hear Scrum practitioners talking about getting a PBI to Done, or that their PBI meets the DoD. But since the
DoD actually pertains to the Increment, these folks are using a verbal shortcut. What they really mean is that when
their work (PBI) is integrated into the Increment, the Increment conforms to the DoD.
• What is the difference between the DoD and the Definition of Ready?
The use of the “Definition of Ready” (DoR) is also a frequently used complementary practice, yet is not a formal part
of Scrum. Similar to acceptance criteria, the DoR applies to your Product Backlog Items. It makes transparent your
team's shared understanding of what prerequisites must be completed for a Product Backlog Item to be brought into
a Sprint.

Based on Scrum.org (The home of Scrum) Página 38

The Professional Scrum Competency

2. Developing People and Teams

Traditional management models consider the work of people and team development to be the job of the team’s
manager. Scrum puts specific responsibility on Scrum Masters to support and guide Scrum Team members (as well as
other members of the organization). However, team development is not only the responsibility of the Scrum Master.
Since Scrum Teams are self-managing, all team members are responsible for helping the team continually improve
through techniques that “develop people and teams.”
This competency has six key focus areas:

1. Self-Managing Teams
The best way to support a team working on complex problems is to give them the space to determine how to do their
work, rather than directing them. Learn about self-managing teams and their characteristics. Explore some myths and
misunderstandings about self-management.

2. Leadership Styles
The ways that leaders present themselves and interact with their colleagues can either support agility, or defeat it.
Learn the difference between leaders and managers and the traits of an agile leadership style. Explore why we speak
more about agile leadership and not servant leadership.

3. Facilitation
Facilitation can be used to lead people toward agreed-upon objectives in a manner that encourages participation,
ownership and creativity by all involved. Learn about the principles of facilitation, skills and traits of a facilitator, how
to facilitate diverse perspectives and explore some facilitation techniques for the Scrum Events.

4. Coaching
The coach’s job is to be a process expert, enabling those they are coaching to achieve their goals using skills such as
developmental conversations, active listening and asking thought-provoking questions. Learn a few of the coaching
principles, traits and skills of a coach, and why coaching is beneficial for Scrum Teams.

5. Teaching
Anyone can act as a teacher, helping your colleagues obtain new knowledge or learn new skills. However, if you want
to become a very effective teacher, it’s best if you learn a few of the principles of the teaching profession, the skills
and traits of a teacher and when teaching can be helpful for a Scrum Team.

6. Mentoring
Mentoring is a mutually beneficial relationship in which a mentor provides guidance to a mentee to help the mentee
reach their goals. It’s often confused with coaching. Learn why mentoring is beneficial for Scrum Team, mentoring
principles, skills and traits of a mentor as well as the traits of a mentee.

2.1. Self-Managing Teams

When teams are faced with complex problems (where more is unknown than known), or given the responsibility to
create an innovative product, they are rarely able to succeed by following someone’s specific instructions. After all, by
its very nature there is no clear way to solve the problem, there are no recipes to follow. The team can only arrive at
the solution by experimenting their way to it. They must create hypotheses, determine how to test their hypothesis
and act on the insights they uncovered through their experimentation.
The best way to support a team working this way is to give them the space to determine how to do their work, rather
than directing them. This space and empowerment is the essence of self-management.
Self-managing teams are those who are given the autonomy to manage their own work. They determine what to do,
Based on Scrum.org (The home of Scrum) Página 39
The Professional Scrum Competency

who should do it and when it should be done. Agile leaders recognize that their role is not to “manage” the team, but
to create the conditions that enable or support their team’s ability to manage itself… and then get out of their way!
For self-management to thrive, there must be:
• Clear goals - The Scrum framework includes two important goals: the Product Goal and Sprint Goal. But, these
aren’t the only goals we’re talking about here. In order for a Scrum Team to understand what to do, they must
be clear on why they are doing it. Why has the team been formed? What problem are they being asked to solve?
• Clear boundaries - Teams are provided the autonomy to make their own decisions. Understanding which
decisions the team can make on their own and which they cannot is key for self-management. Some decisions
may have already been made and are out of the team’s hands. For example, there may be organizational
constraints such as the budget set aside to support the effort, privacy regulations such as GDPR, security
protocols and compliance constraints set by governmental regulations.
• Clear accountabilities - Every member of the team has a role to play achieving the team’s objectives.
Understanding who is accountable for achieving various outcomes helps the team focus on the work.
It’s also important for a self-managing team to be cross-functional and have the skills necessary to perform their day-
to-day work without constantly relying on colleagues outside of the team. Not having the necessary skills on the team
reduces the team’s autonomy and ability to optimally manage their own work.This may require training Scrum Team
members in new skills, so that team members can jump in to pick up work at any given time.
The Scrum framework provides guidance to enable self-management. For example, it describes:
• Goals such as the Product Goal and Sprint Goal
• Boundaries around how to organize the work, such as making the work transparent (the Product and Sprint
Backlogs) and providing Events to enhance communication and collaboration
• Accountabilities within Scrum supported by the Scrum Master, Product Owner and Developers

2.1.1. Characteristics of Self-Managing Scrum Teams

As we mentioned previously, self-managing teams determine what to do, when and how the work should be done and
who does it. This provides a nice framework to recognize if your team is actually self-managing, or is getting undue
direction from outside the team:
• The team manages their work by deciding what they should be doing on a day to day basis:
o Are you operating toward clear goals; does your team use the Product Goal and Sprint Goal to guide their
decisions?
o Does your team focus on the value being delivered?
o Does your team determine how best to fulfill the PBIs; does the team decide what they should be doing
without direction from outside the team?
• The team manages their work by deciding when they should do certain activities. They do this without outside
direction:
o Does the team select a realistic and challenging amount of work for the Sprint and does the team get the
work to Done?
o Does the team choose what and when to release?
• How the members of the team interact with each other gives clues to whether it is a self-managing team:
o Do the developers decide who picks up the work?
o Is the team collaborating to solve problems?
o Does everyone on the team have a voice?
o Do they trust each other?
o Do team members work with and help each other?
• How the team manages their work practices is a good indicator of whether the team is self-managing:
o Do they define and improve their quality practices?
o Do they continually improve their adoption/implementation of Scrum?
o Is the work that’s being done transparent?
o Are they dedicated to doing the work well?
Based on Scrum.org (The home of Scrum) Página 40
The Professional Scrum Competency

o Do they “live” the Scrum Values?

2.1.2. Myths about Self-Management

Few things in Scrum are as misunderstood and misinterpreted as much as a Scrum Team’s need for self-management.
At the highest level, it’s not a very difficult concept, but the nuances tend to throw things into question.
Simply said: the team needs the autonomy to get its work done. However, the phrase “self-management” has led some
to believe that Scrum is anti-management or anti-manager. This is simply not true. In fact, there are several myths that
we’d like to debunk:

Myth: Self-management means that no managers are needed and all of the traditional work of “managers” is done by
people on the team. This could include compensation, hiring, firing, promotions and career development. This also
suggests that Scrum requires flat organizational structures, no titles or individual bonuses.
Reality: Self-management on the Scrum Team doesn’t mean “no managers” in the organization. It’s true that no
managers are required to constitute a Scrum Team, but that doesn’t mean that no managers are required in the
organization.
In organizations that are using Scrum well, the manager’s role switches away from directing the team, toward
supporting the team. They are often the right people in the organization to make sure that the Scrum Teams have
everything they need to be successful, such as the necessary equipment, budget and cooperation from personnel
outside the Scrum Team.

Myth: Self-management means that the team isn’t required to follow rules from outside the team. If they are
empowered to make their own decisions, this means that they can choose to ignore managers and stakeholders and
are unaccountable to them.
Reality: Scrum takes accountability very seriously. The team as a whole is accountable for creating valuable work and
each of the members of the team have clear accountabilities. There is nothing in self-management that encourages
chaos and suggests the suspension of rules from outside the team. Scrum Teams are actually very disciplined in their
work and commitments.

Myth: Teams are completely self-contained, have all the skills necessary to do all the work and should not need to go
outside of their teams for help.
Reality: It’s true that in order to effectively manage their work, the team needs to have the necessary skills to get the
work done. However, complex work often requires the temporary assistance of individuals with specialist skills. Often,
there are too few of these specialists for them to be full-time members on individual Scrum Teams and they must be
shared across many teams. Self-managing teams may not have all the skills necessary, but they are effective
collaborators with colleagues outside their team and together they determine how the work will be done.

Myth: When self-managing teams encounter challenges it’s always best to let them work it out themselves.
Reality: Self-managing teams work hard to remove their own impediments, but this is not a license to ignore challenges
that they cannot overcome. We’ve heard horror stories of “busy” stakeholders who do not provide adequate guidance
on high-level goals or adequate feedback on the work being done, claiming that they are allowing the team to “self-
manage.” Similarly, we’ve heard of Scrum Masters who, upon identifying unhealthy conflict among team members,
ignore the growing team dysfunction and claim that they are allowing the team to “self-manage” their way to a
solution.
Neither of these examples are supporting the team’s self-management, they are examples of abandoning their
responsibilities to the team.

Based on Scrum.org (The home of Scrum) Página 41

The Professional Scrum Competency

2.2. Leadership Styles

The ways that leaders present themselves and interact with their colleagues can either support agility, or defeat it. In
this article, we describe the difference between leaders and managers (which are often confused), identify a few well-
known leadership styles and present the characteristics of an agile leadership style, one that enables empiricism and
self-management to thrive.

2.2.1. The Difference Between Leaders and Managers

The terms “leader” and “manager” are often used interchangeably, yet they are very different concepts. Understanding
the difference is key to understanding the role of leaders and managers in agile organizations.
Managers and Management - As simple as it sounds, managers “manage.” They concern themselves with the day-to-
day operations of the business. Managers generally oversee people, processes or tasks, making certain that work is on-
track. Management is generally an organizational role that comes with a level of authority. Teams are often compelled
to follow the direction of their managers simply because of this organizational authority.
Leaders and Leadership - Similarly, leaders “lead.” Leaders present compelling visions for the future and seek to inspire
people and teams to achieve their common goals. Leaders paint a captivating picture and teams follow them not
because they hold authority over them, but because they believe in the vision and trust the leader. Some of history’s
famous leaders are Mahatma Gandhi, Martin Luther King Jr. and Nelson Mandela.
Some leaders are managers, but not all managers are leaders.
Managers and leaders in Scrum - While there are often managers in organizations, there is no such construct in Scrum.
On the other hand, there can be many leaders on a Scrum Team. For example, the Scrum Master acts as a leader in the
Scrum domain, influencing the team to improve their effectiveness by using Scrum. The Product Owners are product
leaders, creating an enthralling vision of the product and influencing the team to manifest its value. Similarly, any
Developer on the team can also be a leader by using their expertise to drive innovation and deliver value.

2.2.2. What are Leadership Styles?

A leader’s style is the way they present themselves. It includes their demeanor and the methods they use for influencing
others.
There have been countless models of leadership and leadership styles proposed by business schools, organizational
psychologists and various authors. Some include:
• Autocratic, Democratic, Laissez-faire or Transactional leadership
• Compliant, Combative, Competitive or Catalytic leadership1
• Servant leadership2
• And others…
As agilists, we tend to work on complex problems (where more is unknown than is known). Complex problems require
a leadership style that we refer to as “agile leadership.”

1 Described in “The Professional Agile Leader” by Eringa, Bittner and Bonnema

2 This term originates from an essay written by Robert K. Greenleaf in 1970

2.2.3. An Agile Leadership Style

Given the tight connection between agility, complex problems and our focus on Scrum, it makes sense to talk about
the traits of agile leaders in Scrum terms.
Those that use an agile leadership style create an environment where empiricism and self-management can flourish.
For example, agile leaders:
• Act with great humility. They recognize that complex problems have no obvious solutions so there is no need
to show they have all the answers.

Based on Scrum.org (The home of Scrum) Página 42

The Professional Scrum Competency

• Create the conditions that support strong, empowered self-managing teams:

• Help the teams set meaningful goals and help them inspect their progress toward them
• Make certain that the boundaries and accountabilities are clear and well-understood. If they are managers,
agile leaders delegate much of their decision-making authority to the teams
• Foster empiricism by encouraging experimentation. Experimentation centers around creating hypotheses and
then seeking to either confirm or disprove the hypothesis. When a hypothesis is disproved, agile leaders
recognize that this is not the experiment failing, but rather a successful learning process.
• Keep the team’s focus on the value and customer outcomes that the team is creating, rather than managing
the team’s output and activities.
• Creates an environment of trust and transparency by modeling and reinforcing the Scrum Values.
• Use techniques such as coaching, teaching, mentoring and facilitation to build high performing teams. They
do not command or direct the teams to achieve a goal.
• Help teams transition to agility by letting go of old ways of working:
o Agile leaders transform themselves first. They adopt an agile mindset and an agile leadership style.
o Agile leaders focus on value instead of tasks, actions and velocity. So instead of using dashboards and
metrics that don’t support agility, agile leaders use Evidence-Based Management (EBM) which focuses
on four Key Value Areas (current value, unrealized value, ability to innovate and time to market).
o Agile leaders continually look for ways to shift reward structures and promotions away from emphasis on
individual accomplishments to the value that the team creates.

2.2.4. A Word about “Servant Leadership”

Previous versions of the Scrum Guide used the term “servant leader” to describe the style of leadership that Scrum
Masters should use. In the 2020 revision, the term “servant leader” was removed, instead putting more emphasis on
leadership in general. This wasn’t done to discourage Scrum Masters from being servant leaders, but rather to remove
the potential misinterpretation that Scrum Masters are servants first and leaders second. Understanding the idea of
servant leadership is still valuable when using Scrum.

2.3. Facilitation
Facilitation can be used to lead people toward agreed-upon objectives in a manner that encourages participation,
ownership and creativity by all involved. A well-facilitated session can unlock collective intelligence and play an
important role in providing opportunities for people to progress and succeed. Good facilitation enables transparency
and collaboration, creates synergy and leads to achieving a collective objective.
A facilitator plays an important role in helping people to understand and achieve their shared goals and objectives.
They do this while remaining neutral and impartial. Facilitators enable a purposeful and participative environment in
which people feel safe to engage, learn and collaborate. They encourage people to explore different perspectives,
harness diversity and leverage collective wisdom.

2.3.1. Facilitation Principles

The Scrum Values are at the heart of a Professional Scrum Team, guiding them in their work, actions and behavior.
Complementary to the Scrum Values are the facilitation principles of participatory, healthy, transparency, process and
purposeful. Falling back on these core principles can help facilitators work with teams to achieve objectives
collaboratively in different situations. These principles can also help facilitators decide which facilitation skills and
techniques might be appropriate and useful. This holds true not only when creating an energetic environment where
the team is engaged and focused on achieving the objective together, but also when interactions do not go as expected.
Participatory - Core to effective facilitation is full participation and engagement, which enables shared
responsibility in a team
Healthy - A safe environment means creating a healthy space where people feel safe to raise differences and
even conflicting perspectives while respectfully learning from each other

Based on Scrum.org (The home of Scrum) Página 43

The Professional Scrum Competency

Transparency - Transparency only exists when there is shared understanding

Process - Facilitation should enable a team to progress toward the desired objective of the interaction in a
way that is collaborative, inclusive and leverages diverse perspectives

Purposeful - Well-facilitated sessions should have a clear objective that everyone is aligned with and works
toward
These facilitation meeting principles are based on the principles by Certified Professional Facilitator Sean Blair from
SeriousWork and Promeet (https://bit.ly/3p2tT4E); they have been adapted slightly within the context and language of
Scrum.

2.3.2. Skills and Traits of a Facilitator

Facilitators can come from many backgrounds and have varying levels of experience. Great facilitators, however,
demonstrate the following skills and traits:
Active Listening: A facilitator has the ability to listen actively, and focus completely on what is said and what is not
said. They lead by example, inspiring participants to both fully express themselves and engage in active listening when
others are speaking.
Encouraging Curiosity: A facilitator encourages curiosity and different viewpoints. They are skilled in asking powerful,
often open-ended questions, in order to stimulate reflection and discussion.
Problem Solving: A facilitator is skilled at applying group problem-solving techniques. They can help a group define a
problem, reframe it as a clear problem statement and encourage the group to consider a range of solutions to the
problem.
Resolving Conflict: A facilitator recognizes that conflict among group members is natural and, as long as it’s expressed
appropriately, does not need to be suppressed. Conflict should be expected and dealt with constructively and
respectfully.
Using a Participative Style: A facilitator encourages all participants to actively engage and contribute in activities and
discussions, depending on their individual comfort levels. This includes creating a safe and comfortable atmosphere,
in which group members are willing to share their thoughts and ideas.
Encouraging Openness: A facilitator encourages the group to be open to other people’s ideas, suggestions and
perspectives.
Empathizing and Showing Compassion: A facilitator is understanding, aware and respectful of the feelings,
perspectives or actions of others.
Demonstrating Leadership: A facilitator leads a group of people to reach their collective goals and objectives.
Building Consensus: A facilitator is skilled in helping groups to achieve general agreement.
Managing Time Effectively: A facilitator keeps things on course while allowing flexibility. They focus on achieving the
outcome within a timeframe instead of a strict agenda. Overly restrictive time management can stifle good, purposeful
conversations and reflection, whereas a lack of time management can limit focus and progress.
Setting Objectives: A facilitator communicates the purpose of a meeting in a clear and concise manner. This can be
done by setting a strong overarching objective (often done in collaboration with the team) instead of focusing on a
strict agenda.
Communicating Adequately: A facilitator communicates effectively, using clear and concise language.
Being Organized: Facilitation does not start or end with the act of facilitating a group of people. It includes preparation
and following-up on decisions that were made.

2.3.3. Why is Facilitation Beneficial for Scrum Teams?

Based on Scrum.org (The home of Scrum) Página 44
The Professional Scrum Competency

Open and respectful communication will help a Scrum Team thrive as a self-managing team. While members on a
Scrum Team should talk to each other whenever they need to, Scrum assures communication points for the team in
the Scrum events. Every event has a specific purpose and the team benefits from having these events facilitated with
the desired outcome in mind.
Any person on the Scrum Team can facilitate the Scrum events. For example, Sprint Planning is more effective and
exploratory when someone on the team, acting as an objective facilitator, knows how to frame problems to understand
how Product Backlog Items may be valuable for customers. A Developer may be a great person to do that, given their
familiarity with the product.
Often, Scrum events don’t go as planned. Good, lightweight facilitation can help the Scrum Teams get back on track.
For example, if the Scrum Master observes that the team continually uses the Daily Scrum as a status update instead
of an inspection of progress toward the Sprint Goal, then the Scrum Master could help team members to focus by
reminding them of the purpose of the event. This will encourage team members to shift their focus from tasks to how
they can collaborate toward achieving the Sprint Goal.
Taking on a facilitator stance is also valuable for a Product Owner, especially at the Sprint Review when the Scrum
Team and stakeholders inspect progress toward the Product Goal, gather stakeholder feedback and adapt the Product
Backlog accordingly. When done well, the Product Owner and Developers can learn and hear different opinions from
the stakeholders. When not done as well, the Product Owner risks anchoring or limiting the information gathered,
reducing the effectiveness of the Sprint Review.

2.3.4. Facilitation techniques for Scrum Events

Scrum events create regularity and transparency and minimize the need for meetings not defined in Scrum. The events
are the Daily Scrum, Sprint Planning, Sprint Review, Sprint Retrospective, and the Sprint. Often, Scrum events don’t go
as planned. Good, lightweight facilitation can help the Scrum Teams get back on track.
Without good facilitation, the Scrum events can turn into ineffective meetings:
• The purpose of the events may be missed
• People might talk over each other or not talk at all
• We might constantly hear the same few voices and miss out on the opinions of others
• Events can run over their timeboxes without creating necessary action items
• Opportunities to collaborate and progress toward desired outcomes may be missed
The following pieces highlight the purpose of each of the Scrum Events, an indication of where the event’s facilitator
should place their focus, and a few examples of facilitation techniques that can help guide a team to successful
outcomes.

2.4. Coaching
In an agile context, the word “coaching” is used in several ways:
1. Agile Coach - Among agilists, the word “coach” is frequently used to describe the role of an “Agile Coach.” This
is someone who uses agile approaches to help people and teams reach their objectives or overcome
challenges. An Agile Coach doesn’t just coach per se; they also advise, lead, facilitate and teach the teams they
are helping.
2. To describe the discipline of “coaching.” Informally speaking, someone who coaches provides guidance to
help others achieve their professional or personal goals. There are also professional organizations that provide
prescribed courses of study to become a certified coach. These organizations have formal definitions of what
coaching entails.
When we refer to coaching as a Professional Scrum competency, we’re generally discussing the discipline of coaching
(not the role of an Agile Coach) and how coaching skills can be used to increase effectiveness and outcomes of a Scrum
Team and its members.
The coach’s job is to be a process expert, enabling those they are coaching to achieve their goals using skills such as
Based on Scrum.org (The home of Scrum) Página 45
The Professional Scrum Competency

developmental conversations, active listening and asking thought-provoking questions. Strictly speaking, coaches take
a neutral stance with regard to how the person being coached achieves their goals; they do not share their experience,
advice and opinions. (This is in contrast to “mentorship,” where the mentor DOES share their experience, advice and
opinions).
We’re providing the following information so that you can learn more about the discipline of coaching and determine
if further study is interesting to you. However, even if your interest is less formal, the following may provide inspiration
for improvement of your coaching skills.

2.4.1. Coaching Principles

The various certifying bodies for coaching have strict guidance on how coaching is done and how a coach interacts with
those they are coaching. The following are some of the elements of successful coaching:
Intentional - When a practitioner is coaching they are deeply involved and interested in a person or team’s ultimate
success. However, coaches do not have their own agenda, they act on the goals set by the person or group they are
coaching.
Neutral - The coach remains unbiased and non-judgemental about the subject matter. They help people achieve their
goals without steering them. Those being coached are guided to draw on their own experiences and capabilities to
overcome challenges, rather than learning directly from the coach’s experiences. (This is a key differentiator from
mentoring where the mentor actively provides advice based on their own experiences).
Agreed - Formal coaching requires permission or consent in the form of written agreements. These agreements include
the goals of the engagement and coaching approaches, clearly distinguishing between what coaching is and what it is
not.
Systemic - Coaches listen actively to what is being communicated. They seek to find and allow for the voice of the
system (or the whole group, or the unsaid) to be heard. Coaches notice trends and patterns in behaviors and
interactions, then reflect them back to enable richer communication and more effective decision-making processes.
Ethical - Coaches create and manage a unique, safe and inclusive space. For this reason, it’s imperative that they
maintain integrity and confidentiality. For more information, we encourage you to explore the International
Coaching Federation’s Code of Ethical Conduct as well as the Agile Alliance’s Code of Ethics for
Agile Coaching.

2.4.2. Traits of a Coach

Successful coaches demonstrate capabilities from both agile and coaching areas of expertise. In order to have a holistic
approach to coaching, we suggest agilists develop proficiency in the following areas:
• Supports the Team’s Self-Management - Self-management is founded on the assumption that everyone on the
team has valuable ideas and is responsible for their own outcomes. When coaching, you have a responsibility
to help uncover ways of developing self-management, including your own.
• Models the Scrum Values - In the context of Scrum, sharing common values is central to building an
environment of trust where people feel encouraged to inspect and adapt toward shared goals. When coaching,
you have a unique opportunity to model the Scrum Values and bring awareness of their merit to the team. Here
are some examples to draw on:
o Courage: Challenge new ways of thinking and offer support in exploring them.
o Commitment: Encourage commitment to action and help build the right plan for accountability.
o Focus: Focus the team on the topic, and bring their attention to emerging thoughts, and inquire how they
want to proceed.
o Openness: Model and promote openness, creating a safe and open space where everyone feels
comfortable to fully express themselves.
o Respect: View your colleagues as creative and resourceful. Allow their solutions, ideas, and thoughts to
emerge throughout the conversation.
• Navigates Complexity… in Human Relationships - People are complex. Navigating this complexity requires

Based on Scrum.org (The home of Scrum) Página 46

The Professional Scrum Competency

emotional/social skills like listening, empathy, and building shared understanding.

• Encourages the Team’s Growth through Empiricism - Empiricism is the growth of knowledge through
experience. Empiricism is foundational to Scrum. When we help the team focus on a defined problem, apply
small changes and use the evidence of what happened to build their understanding, they generate new
solutions and options for themselves.

2.4.3. Coaching Skills

Coaching requires you to leverage a wide range of skills. Successful coaching requires you to work with what is present
and make choices in the moment. This means developing proficiency in many skills:
• Listening Actively - Recognize that people communicate with more than their words. Their context, identity,
environment, experiences, values and beliefs must be taken into account. Pay attention to their body language,
mood, emotion and hear what is unsaid through their words and actions.
• Asking Powerful Questions - Ask questions that are open-ended (cannot be answered by “yes” or “no”), neutral
and short. The key is to choose questions that provide the opportunity for the person you are coaching to gain
new insight or reframe their perspective. Powerful questions are best applied when you are also listening
actively.
• Reframing - Invite the person you are coaching to take an alternate point of view to broaden their range of
solutions and consider multiple perspectives.
• Reading and Working with the Emotional Field - Coaching requires that you actively monitor the atmosphere,
energy, or mood of the coaching space. As it changes during the coaching session, try to bring curiosity and
reflection on it into the conversation to deepen an understanding of what's going on. The emotional field is a
phrase commonly used by practitioners who have studied Organization and Relationship Systems Coaching
(ORSC)™.
• Normalizing - Create a feeling that the person you are coaching is not alone in the challenges they face. When
used well, normalizing has the ability to reduce tension or frustration and open people up to new ways of
thinking.
• Supporting with Silence - Sometimes called “awkward silence,” this is a situation where you and the person
you are coaching are both quiet and present, waiting for the wisdom and intelligence of the person being
coached to emerge.
• Taking a Meta-View - Seek to observe the situation from the highest perspective to see the whole picture,
uncover new information and connect what previously seemed to be disparate information.
• Holding Things Lightly - When you hold something lightly you acknowledge its presence and avoid allowing the
topic or information to consume the conversation or overshadow the topic at hand.
• Bottom-lining - Be clear and precise with your words in order to create a “mic-drop” moment. Avoid over-
explaining or asking long questions that interweave too much context.
• Forwarding the Action - Be intentional about how the person you’re coaching will move forward in action as a
result of the coaching conversation.

2.4.4. Why is Coaching Beneficial for Scrum Teams?

Knowledge workers, particularly Scrum Teams, who are constantly navigating change and being challenged to innovate,
can often benefit from the guidance of an external, professional coach.
Scrum Masters often take the role of a coach with their teams. However any member of the Scrum Team can use
coaching skills informally or organically to help the team improve its effectiveness. Examples include:
• Using coaching skills during the Scrum Events - any team member can use coaching skills to help the team use
their knowledge and experience to determine next steps
o Sprint Planning - ask powerful questions to help the team determine how the work for the Sprint is going
to be done.
o Daily Scrum - use active listening to uncover what challenges may not be expressly articulated during the
Daily
o Sprint Retrospective - use normalizing when the team is facing challenges in working together. It may be
Based on Scrum.org (The home of Scrum) Página 47
The Professional Scrum Competency

important for them to understand that they are not the only team to face these challenges.
o Sprint Review - use reframing to encourage stakeholders to consider a new perspective
• Using a combination of coaching skills to manage the complexity around collaborating or communicating within
and outside of the team, particularly with building relationships with stakeholders

2.5. Teaching
There are many ways for a team member to learn from another team member. They can:
• ask a more senior member of the team to mentor them,
• they can engage with someone who acts as a coach,
• they can simply observe a colleague,
• or they can ask a colleague to teach them something that they'd like to learn.
At the highest level, teaching is about transferring knowledge from the teacher to the learner so that the learner
acquires new knowledge or skills.
You, or anyone on the team, can act as a teacher, helping your colleagues obtain new knowledge or learn new skills.
However, if you want to become a very effective teacher, it’s best if you learn a few of the principles of the teaching
profession.
Scrum.org recognizes that those studying to become professional teachers or trainers go through an extensive learning
and certification journey. Our goal in these pages isn’t to replicate those learning journeys, but instead to make Agile
practitioners aware of what the practice entails so they can incrementally improve their teaching ability and seek out
further resources.
It’s easy to fall into the trap of thinking that if you want to teach something to someone, you can simply stand before
them and lecture them on the topic. Particularly in a professional setting, that’s neither very effective nor well-received.
So, how can you become a better teacher? Scrum.org suggests that at a minimum, you become familiar with how
people learn, how to effectively convey information and how to assess that the learner’s objectives have been
achieved.

2.5.1. Teaching Principles

It’s easy to fall into the trap of thinking that if you want to teach something to someone, you can simply stand before
them and lecture them on the topic. Particularly in a professional setting, that’s neither very effective nor well-received.
So, how can you become a better teacher? Scrum.org suggests that at a minimum, you become familiar with how
people learn, how to effectively convey information and how to assess that the learner’s objectives have been
achieved.

Learners learn differently

Certified teachers and trainers delve deeply into cognitive science and learning theories. As someone who just wants
to do a good job teaching something to a colleague, you should be aware that the way you may initially want to teach
something may not be the way your colleagues will best learn it. There are many, sometimes conflicting, theories about
learning styles. Whatever the differences may be, there seems to be general agreement that using different teaching
methods is important for helping learners be successful.
The following is a short list of teaching methods and models. It’s not meant to be a formal education on teaching
methods, but rather to spark your creativity:
• Lecture: There are learners who benefit most from a more traditional style like lecturing. This involves speaking
to the learner(s) about the topic while they possibly take notes to reference later. Learners can then ask
clarifying questions at the end of the lecture or at some point afterwards.
• Self-study: Learners who benefit more from watching videos and reading any materials that are provided to
them are likely to absorb the information better while engaging with it on their own. It allows them the time
and space to understand the topic at their own speed.

Based on Scrum.org (The home of Scrum) Página 48

The Professional Scrum Competency

• Hands-on: Many people prefer to learn by doing. Having a learner interaction with the concept through
activities may prove useful to them and make it easier for them to learn the material.
• Assignment-based: This method helps people who learn by doing but prefer to do it on their own or in a small
group. The method involves teaching the subject to the learner(s) before either giving them an assignment that
requires them to apply the concepts or asking them to teach the subject back to you. It demonstrates that they
were able to properly understand what was taught to them and how it is applied.
• Experiential Learning: In this model, learning is a cycle that starts with hands-on learning; followed by reflection
and thinking about the experience; which leads to experimenting with what was learned.This style is particularly
well-suited to Agilists for whom experimentation, reflection and adaptation are second nature.

Instruction should be designed around learning outcomes

As agilists, we feel strongly that the work we do should be based on the outcomes we seek to create. In teaching, we
start by determining what learning outcomes the learners need to achieve. Once that’s established, we design the
content of the instruction in a way that achieves each of those goals.
Assessment of the impact of the lesson helps the learner and the teacher
Frequent feedback is a key tenet of Scrum. It helps the Scrum Team either continue on their current course, or adapt
and change their approach. The same concepts hold true for teaching. When a learner is provided the results of an
assessment, they can uncover whether they have achieved their learning goals, or if they need to consider another
approach to learning.
Just as Scrum includes the Sprint Retrospective to assess whether the team used methods that were effective in
achieving the Sprint Goal, a teacher should spend time reflecting on whether their methods were effective in helping
the learners achieve their learning objectives.

2.5.2. Skills and Traits of a Teacher

Teachers come from varying levels of experience and different backgrounds. However, great teachers often have the
following qualities:
• Humility: Someone who is teaching should have a humble attitude in order to make themselves more
approachable and provide a safe environment for learning.
• Subject Matter Knowledge: Teachers must have confidence in the subject they’re teaching. Being able to
answer questions without preparation will help teach as well as give learners confidence in the knowledge they
are receiving.
• Patience: Teachers should have patience with their learners. Creating an environment that is not welcoming to
those who may need more help will discourage them from learning.
• Empathy: Being understanding of those who are learning is an important quality when teaching. A teacher
should be able to put themselves in the position of the learner in order to assess whether or not they are
teaching effectively.
• Adaptability: When teaching, one should be able to change their teaching style when needed. If a concept they
are teaching is understood faster than expected, move on to the next portion. If the concept is not well
understood, shift to another style of teaching to accommodate the learners or material.

2.5.3. When Can Teaching Be Helpful for a Scrum Team?

There are many ways that teaching plays a role in helping a Scrum Team grow, improve and have a shared
understanding. Examples may include:
• A Scrum Master can teach a Scrum Team about complexity theory and its connection to the fundamentals of
the Scrum framework
• A Scrum Master can teach a new Product Owner how to create and order a Product Backlog based on factors
such as priority, risk, value and dependencies
• A Developer teaches their team about concepts they learned in their UX course that they think will be helpful
for his team to consider when building the product
Based on Scrum.org (The home of Scrum) Página 49
The Professional Scrum Competency

• A Product Owner teaches other Product Owners in a community of practice on how to use a lean canvas when
pursuing new initiatives
• A Product Owner teaches customers and stakeholders about the product

2.6. Mentoring
Mentoring is a mutually beneficial relationship in which a mentor provides guidance to a mentee (also sometimes
referred to as a protégé) to help the mentee reach their goals. Mentoring is often confused with coaching since they
both heavily rely on developmental conversations, active listening and asking thought-provoking questions. However,
unlike coaches, mentors actively share their experience, advice and opinions, often acting as a role model and advocate
for their mentee.
Your organization may have a formal mentorship program set up by the company to help newer or less experienced
staff members. Companies often sponsor these programs in order to help fulfill business goals such as increased
employee retention, diversity enhancement, skills and career development, or new-hire onboarding.
Often, no such program exists and it’s up to individuals to either become a mentor or seek out a mentor. These pages
are designed to help you determine if mentorship is something you feel is worth pursuing.

2.6.1. Mentoring Principles

When companies have formal mentoring programs, they may have established procedures for how mentors and
mentees are matched, and how each conducts themselves during the mentoring relationship. However, when no
formal program exists, it’s up to the mentor and mentee to figure out how they will work together. We’d like to share
some of the elements of successful mentorship that has guided us in the past:
• Connection - Fundamentally, the most important thing is that the mentor and mentee want to work together
in mentorship. The relationship must be based on mutual trust and respect.
• Intentional - At the core of mentorship is a focus on understanding and supporting the mentee’s career and/or
developmental goals. It’s important for the mentee to be able to articulate their goals to their mentor and for
the mentor to be confident in their ability to appropriately guide their mentee.
• Active - The mentor actively provides advice and guidance to the mentee, sharing anecdotes from their own
experiences and providing crucial feedback. The mentee receives feedback and takes responsibility for
implementing the lessons learned from the mentor.
• Clear - Both the mentor and the mentee must be clear that they are establishing a mentoring relationship and
should set appropriate expectations to avoid disappointment. Whether you and your mentor or mentee create
a written agreement is entirely dependent on your particular circumstance. For some, this level of clarity is
important. For others, it is excessive formality.
• Limited - Mentoring relationships can be fairly long-term, ranging from many months to years. It’s often useful
to create an understanding of when the mentoring relationship will end. This can be based on a specific lapsed
time, or better yet, the achievement of certain goals. The mentoring relationship is successful if the mentee
advances enough to no longer need the support of the mentor.

2.6.2. Skills and Traits of a Mentor

• Experienced - Having the appropriate background is crucial for being able recount your own experiences and
to provide pertinent advice to your mentee.
• Knowledgeable - Your mentee will come to you wanting to achieve success in a particular domain. It’s important
to have knowledge of that domain.
• Supportive - You should be able to engage in active listening and asking powerful questions in order to stimulate
your mentee’s reflective thought process. It’s important to listen to your mentee’s goals and concerns and base
your guidance on what you heard. You must be capable of delivering feedback in a way it can be received by
your mentee.
• Committed - You must be dedicated to your mentee’s personal and professional development and success.
Mentors are often willing to expend their own political capital in order to advocate for their mentee’s career
Based on Scrum.org (The home of Scrum) Página 50
The Professional Scrum Competency

advancement within the organization.

• Approachable - As a mentor, you should be able to create an atmosphere of openness and trust. Your mentee
should feel comfortable talking about potentially awkward topics and you should be willing to share personal
and professional information in order to help your mentee.
• Focused - You should have the ability to help create clarity and direction for your mentee. This could take the
form of goal setting, next steps, action items or anything that would help the mentee move forward on their
goals.

2.6.3. Traits of a Mentee

Before you seek out a mentor, you should make certain that you’re prepared to be mentored. In particular, mentorship
works best if you are working on specific goals.
Ask yourself the following questions:
• Have you recognized that you are facing a particular challenge with which you want support?
• Do you have the ambition to advance in your career or achieve a goal?
• Are you willing to actively seek feedback and act on it?
• Are you ready to take responsibility and ownership of the interaction with your mentor and drive toward your
objectives?
• Do you have the time to devote to the relationship?
• Are you comfortable sharing potentially uncomfortable topics if it helps you succeed?

2.6.4. Success with Mentorship

The formality of the mentoring relationship is based on the needs of the people involved. It can be very formal, with a
written agreement of the goals, details of how they will interact, documented progress reviews and formal kickoff and
closing meetings. Formal mentoring relationships are most common with company-sponsored programs and when the
mentor and mentee do not have a prior relationship.
More informal relationships often occur when a mentor and mentee are acquainted and find that entering a mentoring
relationship would be rewarding. They may not create a written agreement on how to conduct the relationship, but
they should consider the principles of mentorship and the traits of both the mentor and mentee.
Finally, there can be ad hoc mentoring relationships. These mentoring opportunities tend to occur when the mentor
and mentee work closely together. As ad hoc as these interactions may be, it’s important that the mentee agrees to
be mentored and it must be in the style the mentee feels is appropriate. Making certain that this understanding is in
place mitigates the risk that the mentee feels they are being treated as an inferior, creating resentment between two
colleagues.

2.6.5. Why is Mentoring Beneficial for Scrum Teams?

While the Scrum Master has specific accountability for mentoring Scrum Team members on the use of Scrum, every
team member has knowledge and experience that will benefit their colleagues. These relationships can be within or
outside of the Scrum Team.

Mentorship examples on Scrum Teams

It’s rare for formal mentoring relationships to be formed among members of the same Scrum Team. For example, it’s
difficult to act as a sponsor to a peer on your team. However, due to the self-managing nature of Scrum Teams,
mentoring relationships are continually forming. Mentorship within a Scrum Team is generally ad hoc with one team
member with particular prior experience guiding other team members. We sometimes refer to this as taking a
mentorship “stance.” For example:
• When a team member has experience that could help their team reach a desired approach or outcome, or
support their team’s decision
• When the team is trying a new approach or solution and one team member has prior experience with a similar

Based on Scrum.org (The home of Scrum) Página 51

The Professional Scrum Competency

situation
• A newly hired team member can be mentored by a longer-standing team member
• There is often the possibility of cross-role mentorship when developers, POs or Scrum Masters want to be
mentored in other roles
• A team member may mentor others on the benefits of empiricism, self-management and continuous
improvement by recounting their prior successes with them
• When a new team is formed, there may be opportunities for mentorship around setting a successful mission,
team values and goals
• Teams often struggle with how to steer toward or evaluate their successful outcomes. A team member with
experience with Evidence-Based Management (EBM) or Objectives and Key Results (OKRs) may be able to guide
the rest of the team.

Mentorship outside of your immediate Scrum Team

Mentorship outside of your immediate team is more likely to take the shape of a more traditional mentoring
relationship. For example:
• If you have significant experience as a Scrum Master, Product Owner or Developer, you may be asked to mentor
someone with less experience in these roles
• There are opportunities to participate in mentorship structures such as communities of practice, or during
hackathons or peer reviews
• Often less experienced team members benefit from having mentorship around how the organization operates
• Setting up a new team or introducing Scrum requires the benefit of experience. Having a mentor with this type
of experience can be invaluable.
• Mentorship is not restricted to junior team members, the organization’s leaders can often benefit from having
mentors guide them in understanding how operating in an empirical way impacts the organization and its
structure

Based on Scrum.org (The home of Scrum) Página 52

The Professional Scrum Competency

3. Managing Products with Agility

Managing Products with Agility results in products that provide valuable business outcomes, increased flexibility to
respond to change, and greater transparency for investment decisions in product development. A clear and
understandable Product Vision helps to align product development with the organization’s Business Strategy including
strategic goals and/or business vision, while a focus on Product Value addresses the continuous improvements to the
product to meet customer needs. Product Value includes considerations such as greater transparency in value-based
decisions and organization-wide, value-driven approaches. Key tenets of this Focus Area include continuously defining
value, measuring actual value realized, validating assumptions, and analyzing trends.
The process of aligning Product Vision with Product Value is iterative and incremental, and it is managed through
continuous refinement of the Product Backlog. Effective Product Backlog Management requires input and
collaboration from a variety of Stakeholders and Customers - including the Scrum Team - and requires evolving
techniques to ensure appropriate levels of transparency based on the needs of stakeholders. Similarly, Forecasting and
Planning uses an iterative and incremental approach to manage complexity, change, and the realities of business
obligations. Attention to these Focus Areas results in development and delivery of valuable product increments within
30 days or less. Additional features and benefits of these approaches include increased transparency to progress, more
realistic and evolving forecasts to manage stakeholder expectations, and applying appropriate release, sales,
contracting, and partnering strategies.
The Product Owner is typically focused on Managing Products with Agility, however, proficiency in this competency is
required by all Scrum Team members, Agile Leaders, and organizational stakeholders to ensure that the full value of
using the Scrum framework and an empirical process is achieved.
This competency has the following key focus areas:

1. Forecasting and Release Planning

Scrum Team can use forecasting and release planning as a guide for delivering a product through small incremental
and frequent releases rather than big bang product launches.

2. Product Vision
The Product Vision describes the purpose of a Product. A good Product Vision expresses the value the Product should
deliver and to whom that value is delivered.

3. Product Value
The objective of a Scrum Team is to deliver value to customers and stakeholders. Product Value actively drives
customer satisfaction, loyalty, brand reputation, and the longevity of a business by providing customers with benefits
that satisfy their needs.

4. Product Backlog Management

Product Backlog Management is the act of adjusting and ordering items on the Product Backlog so that the Scrum Team
can deliver the most valuable product possible. This learning series explores Product Backlog Management.

5. Business Strategy
Business strategy is informed by the company’s mission and vision, and in turn informs individual product visions. An
organization inspects and adapts its business strategy based on feedback gathered from delivering product Increments.

6. Stakeholders and Customers

Scrum encourages frequent collaboration with stakeholders, and customers in particular. Understanding how to
identify and learn about the challenges that key stakeholders face will help the Scrum Team better deliver the value
they are seeking.

Based on Scrum.org (The home of Scrum) Página 53

The Professional Scrum Competency

3.1. Forecasting and Release Planning

3.1.1. Forecasting
A forecast is a prognosis or estimate of future events*, trends, or outcomes. It is made based on known information
and analysis of past and present conditions.
In product development, forecasting is commonly used for Release Planning to create alignment and to manage
expectations for everyone involved on when new products or new features will be delivered.
A Scrum Team can forecast the delivery of Product Backlog Items (PBIs) based on their trends and history if they seek
insight into when work may be completed on the Product Backlog. However, it is important to know that their forecast
is by no means a commitment or guarantee due to the complex nature of their work.
*definition from Oxford Languages Dictionary

3.1.2. Release Planning

A product release is when a team delivers a new or updated experience to their customer in order to gain feedback
and deliver value.
Scrum Teams can use release planning as a guide for delivering a product through small incremental and frequent
releases rather than big bang product launches. The benefits for planning and carrying out frequent small releases are:
• Opportunities for faster user feedback, learning and course correction
• Reduced risk: potential issues are caught earlier
• Improved focus and transparency on progress toward goals
• Increased effectiveness
Keep in mind that when a Scrum Team uses practices such as continuous integration, continuous delivery and
continuous deployment, they can deliver to customers at any point in time. This allows them to release several times
during a Sprint, or even several times a day. In this case, release planning involves shorter-term plans and the team
must validate that the product Increments they are delivering are actually delivering value, while focusing on what
their next experiments will be.

3.1.3. Forecasting, Release Planning and Complexity

When communicating forecasts, Scrum Teams should be sure to include the uncertainty involved. Everyone in the team
as well as stakeholders must understand that their forecasts will change as more information emerges, conditions
evolve and impediments are identified and removed. These include anything from technical and development
complications, changes within the team, unforeseen dependencies, uncertain customer behavior, and evolving market
conditions.
Planning and Updating Forecasts within a Sprint
During Sprint Planning Scrum Teams can use historical data such as throughput to forecast the amount of work they
believe they can deliver in a Sprint. This Sprint forecast, together with the Sprint Goal and an actionable plan for
delivering the increment forms the Sprint Backlog.
The Sprint Review is an opportunity for the Scrum Team to update and make transparent its latest forecast and progress
toward the Product Goal with their stakeholders. Based on what they learn, the Scrum Team makes changes to their
Product Backlog as needed to take advantage of emerging opportunities. Such changes can then be incorporated into
an updated forecast and release plan in near-real time.

3.1.4. Forecasting Techniques

There are many forecasting techniques that Scrum Teams can use as complementary practices to Scrum, and they all
have their pros and cons. However, their real value comes from the Scrum Team using them to drive conversation
internally and with others.

Based on Scrum.org (The home of Scrum) Página 54

The Professional Scrum Competency

Burn-down and Burn-up Charts

A burn-down or a burn-up chart can be used to create transparency on the progress that a Scrum Team is making over
time toward the completion of a given amount of work.
The difference between the two is that a burn-down chart shows the work that is still remaining at a point in time,
while a burn-up shows the amount of work completed toward a target. “Work” could be expressed as the number of
Product Backlog items, story points or some other measure. Both charts allow the Scrum Team to make transparent
actual progress of completed work over time. Based on the progress trends, they can project completion of all work,
or how much work might be delivered by a certain date. Uncertainty of forecasts can be captured by projecting an
optimistic projected trend line and a pessimistic projected trend line, creating what is called “the cone of uncertainty”.
The result is a range of when the work might be delivered. The further ahead a Scrum Team looks, the wider the cone,
capturing the fact that forecasting is less certain the further that we look into the future.
Burn-down and burn-up charts have the advantage
of being relatively simple to create and they are
fairly intuitive to understand. However, they give no
indication if value is actually being delivered. As
such, they are used for tracking progress in the form
of outputs instead of outcomes, and it is easy for
Scrum Teams and their stakeholders to focus on
completing the originally forecasted work as the
target rather than monitoring progress toward
fulfilling their Product Goal. Also, in the case of
burn-down charts, they give limited transparency of
what is actually happening. For example, consider a
Scrum Team who gets nothing done in a Sprint and
one that gets lots done but adds the same amount
of work back to the Product Backlog. In the same
Sprint, those two teams will have similar looking burn-down charts.
Probabilistic Forecasts
A probabilistic forecast is a calculation that forecasts when a certain item will be
completed. For example, based on the following calendar, the forecast could take a form
such as: there is a 85% chance that it will be completed by February 11, 2018, but only a
50% that it will be completed by February 3, 2018.
Probabilistic forecasts can be used for the completion of single items, whole Product
Backlogs, or how much of a Product Backlog might be done by a certain date. They are
commonly created using Monte Carlo simulations and are based on a Scrum Team’s
historical performance.
Probabilistic forecasts help to
communicate uncertainties
since the language of
probabilities is one that most
people can understand.
However, these types of
forecasts are not trivial to
create and can be flawed as the
quality of the simulation is only
as good as the input data.

Based on Scrum.org (The home of Scrum) Página 55

The Professional Scrum Competency

3.1.5. Release Planning Techniques

Forecasting provides information required for release planning. Similar to forecasting techniques, there are release
planning techniques that Scrum Teams can use that are complementary to Scrum. There are benefits and challenges
with each. What is important is that the team focuses their conversations and plans on what they are trying to achieve
with each release. They should start with the Why? and considering the Evidence-Based Management concept of
Unrealized Value, which is the “satisfaction gap” between the outcomes that customers currently experience and the
outcomes that they would like to experience.

How will this release help the team satisfy the satisfaction gap that customers currently
have?
Release Planning Questions to Explore
Most people consider release planning as merely a tally and forecast of when certain Product Backlogs items could be
delivered. However, Scrum Teams can use release planning in a way that focuses on delivering value to customers
effectively by also exploring questions such as:
• What are we trying to achieve with each release? What customer and user outcomes are we aiming for?
• What features might fulfill those outcomes that we should include (and which ones should we not include)?
• What is our forecast? When should/ can we release what?
• What will we measure to validate the value of the release?
• Are our stakeholders and customers able and ready to adopt the changes we want to release?
• Are there any dependencies we need to take in consideration?
• What potential obstacles could delay our release?
• Who needs to be involved?
• Is everyone, including stakeholders, on the same page?
• How do we communicate/ manage expectations?
Story Mapping
User Story Mapping is a technique developed by Jeff Patton that is described in his book, User Story Mapping: Discover
the Whole Story, Build the Right Product. A Scrum Team can use story mapping to develop a multidimensional view of
their Product Backlog as it links together a user’s journey using a product, the work that is required to satisfy these
activities and how those user stories can fit into Sprints and releases.
Road Mapping
Roadmaps are a technique that
Scrum Teams use for planning
releases. For roadmaps to be
useful for a Scrum Team, they
should be incomplete, allowing the
Product Owner to make decisions
as the team adapts to what they
learn from each release.
The roadmap then serves as a
flexible tool to discuss vision, goals,
strategies and opportunities
instead of a fixed list of work for x
amount of time. You can consider
a roadmap to be an agile anti-
pattern or a trap when it is used merely as a different visualization of a project or program plan.

3.1.6. Conclusion to Forecasting and Release Planning

For forecasting to be helpful, Scrum Teams need to do it on an ongoing basis. They should update their forecasts and
Based on Scrum.org (The home of Scrum) Página 56
The Professional Scrum Competency

release plans as more information becomes transparent.

Whatever approach a Scrum Team takes with regards to Forecasting and Release Planning, everyone should keep in
mind that a release forecast is not a promise and does not replace the importance of empiricism. In complex
environments, the future is unknown.

3.2. Product Vision

The Product Vision describes the purpose of a
Product. A good Product Vision expresses the value
the Product should deliver and to whom that value is
delivered. It is effective when people connect with
the vision emotionally and practically. When a
Product Vision is both aspirational and actionable, it
inspires creativity within the Scrum Team allowing
them to collaboratively work with Stakeholders on
how they might work toward the vision.
The Product Vision is owned by the Product Owner,
but its development requires input from
stakeholders and the Scrum Team(s). A good Product
Vision is built incrementally allowing many
opportunities for inspection and adaptation.
The Product Vision should be a free-standing,
transparent instrument that enables stakeholders
and the Scrum Team to understand the intention of
a Product. However, even though it should stand on
its own, a Product Vision exists in the context of two
other critical elements: Business Strategy and
Product Strategy.

3.2.1. Business Strategy and Product Vision

The business strategy provides a clear, actionable plan for the business. It describes the initiatives that the business
will undertake in pursuit of the company's mission. The business strategy provides the context for the organization's
products and services. For the Product Vision, the business strategy should provide the business guardrails for the
product to operate within. For example, the business strategy will describe market focus, pricing and value assumptions
and have ideas on growth. The Product Vision describes the direction of the product in pursuit of that strategy.

3.2.2. Product Strategy and Product Vision

The product strategy takes the vision and tells you how that will be executed. The strategy can include a Product
Roadmap, which represents a view of the key product milestones that the product strategy describes. The product
strategy will define the product's persona(s), the problems the product will solve, and what success looks like. The
Product Strategy defines the Product Goal, which is a commitment to the Product Backlog. The Product Goal provides
guardrails for the Product Backlog enabling choices to be made about what should be in or out of the Product Backlog.
The reality is that this understanding will change over time, requiring an iterative process. Each Sprint is an opportunity
to review the Product Vision, Product Strategy and other elements of the business to ensure that they still make sense.

3.2.3. Characteristics of a Product Vision

The detail of a Product Vision will depend on the situation. For example, a Product Vision for a new corporate loan tool
would differ significantly from one created for the next generation of online football games. Not only is the subject
matter different, but the audience is as well. The Product Vision should be stated in a way that the Scrum Teams

Based on Scrum.org (The home of Scrum) Página 57

The Professional Scrum Competency

working on the product and the stakeholders involved in the work have a shared understanding of it. It should be
written in the language of its audience.
A Product Vision should provide the glue that connects the work of the Developers with the strategy of the business
and organization.
A good Product Vision should be:
• Compelling and aspirational - The number one responsibility of a Product Vision is to encourage others to join
the journey. That means that the vision must connect to the people reviewing it. It must describe a cause that
is worthy and inspiring. This can be challenging for the Product Owner for more traditional products within
existing situations. In those situations, it is essential to focus the vision on the users and the value that the
product creates for them.
• Aligned and connected - A product needs to fit the business strategy. Using language that aligns the Product
Vision with how the organization describes the strategy is essential. Using the exact words can help provide that
alignment and ensure that the stories that describe the Product Vision connect to stories about the business
strategy.
• Transparent and concise - A Product Vision does not sit on a shelf, gathering dust, but should be available and
accessible for everyone. This transparency ensures that everyone is working towards the same goal. It should
also be stated simply allowing people to consume its information quickly. It also can change and will change as
our understanding of the marketplace changes or the opportunity that technology provides.
• Human and relatable - By connecting the product to the people using it, the Product Vision can be more
compelling and understandable. The audience for a Product Vision may have many different levels of technical
and business knowledge however, the one universal connection point is the people benefiting from the Product.
By drawing that connection, the vision is more transparent and better understood.
• Clear and unambiguous - Often easier said than done, but the Product Vision must provide guardrails for what
will be worked on. Saying no to Product Backlog items is one of the most valuable things a Product Vision can
provide. As much as a Product Vision says what the product will achieve, it also says what the Product will not
do. A good Product Vision constrains the Product Strategy and provides focus.

3.2.4. Communicating the Product Vision

There are many different ways of expressing a Product Vision. The most important aspect of a Product Vision is that it
is simple and in a form that the audience can understand and relate to. That may mean having different representations
of the Product Vision for different audiences. For example, one audience likes a presentation and another wants a
simple statement. One audience is interested in the product's audience, another is more focused on the high level
features or needs. However, when there are multiple representations of a Product Vision, those items must be kept
up-to-date and connected.
One approach to describing the Product Vision is a simple statement that describes the Product. This is also known as
an elevator pitch.

Some Product Owners like to keep all the elements that can be part of the Product Vision on one board. These are
Product Vision boards and can help communicate the product to multiple stakeholders. Boards can be comprehensive,
Based on Scrum.org (The home of Scrum) Página 58
The Professional Scrum Competency

including problem definition, user and customer personas, goals and even include notes on the type of user experience.
Other boards can be simpler, providing an elevator pitch or simple statement. What is important is that they are
readable and tuned to their audience. It is not the board that is important, but how the information on the board is
received by its audience. A very detailed Product Vision can confuse an audience, a very simple Product Vision can
leave the audience wanting more. The challenge is finding the right balance and that will require exploration with the
Scrum Team and stakeholders.

3.3. Product Value

Product Value is the benefit that a product provides to a customer to increase their satisfaction and needs. It can also
be considered as the benefit that the organization gains from the product represented in terms of money, or benefit
to society. When a team and organization deliver value, they are contributing to aspects like customer satisfaction,
customer loyalty, brand reputation and the longevity of a business - business value.
It is important to know that the only way for a Scrum Team to deliver product value is to release a product Increment.
Teams and organizations should
monitor and understand a
product’s value in order to
manage a product, product
portfolio and business strategy
effectively. They must keep
product value in focus by regularly
validating whether their products
are valuable by measuring the
value their products deliver.
Otherwise, they are producing
waste.

3.3.1. Common Mistakes to Avoid when Seeking Product Value

Validating whether a product is valuable is often a challenge for teams and organizations, because they are often in a
rush to deliver to market quickly and focused on their efficiency and speed. Here are some common mistakes to avoid
when understanding and seeking product value:
• Assuming something is valuable to a customer just because the customer asked for it. While the customer
may think they want something, it does not mean they will use it.
• Assuming that internal stakeholders know best what customers need. Internal stakeholder and feedback is
important, but there is no guarantee that internal stakeholders like management or subject matter experts
know what customers need
• Maximizing output (deliverables) to achieve more value. More output does not equal more value. Various
studies show that only a third of ideas are valuable in successful organizations.* Running and validating
experiments gives the team better information that will help them progress in a better informed and deliberate
manner.
• Creating new features or fixing all bugs for the sake of it. Your customer may not want new features and will
not use them if they find them unhelpful or hard to adapt to over a previous version of a product. They may not
know a defect exists in your product. Pushing out new features without understanding how they would satisfy
a customer’s needs can bloat your product and be expensive to maintain.
• Trying to determine value upfront for an extended period of time. In a complex and uncertain environment
this can be misleading and a waste of time! Instead, the team should work toward Product Goals that are in
pursuit of a larger aspirational strategic goal. This allows the flexibility for the team to pivot as they learn new
information.
• Ignoring changing customer behavior, where your product is in its lifecycle, and market demands. Passing this
information over can lead to the end of your product as your customers find better solutions. Be sure to
Based on Scrum.org (The home of Scrum) Página 59
The Professional Scrum Competency

measure the current and future opportunities of your product and the size of the customer’s satisfaction gap
and act on that evidence appropriately.
• Adding more people to a team to deliver more value. Organizations sometimes assume that adding more
people to a team means that they can deliver faster and thus create more value for their customers. The
opposite is often true. Adding more people to a team can slow down progress. Changing team structure comes
with learning curves and other costs. And, as mentioned, more output does not mean more value.

3.3.2. What makes a product valuable?

A product is valuable in three ways.
• It helps a customer achieve something that they want to achieve, some positive outcome that they desire. (e.g.
satisfied and happy customers)
• It creates a positive impact for the business in money terms when customers use it. (e.g increases in revenue,
profit, and market share)
• It creates a benefit for society, not necessarily represented in money terms. (e.g. aid delivered, community
engagement)
Positive Outcome
A positive outcome is an experience that helps to make a person’s life better. Positive outcomes help people to achieve
their goals. A product that enables positive outcomes helps customers to achieve things that they could not otherwise
achieve without your solution.
Business Impact
Business Impact refers to the impact that actions have on a business' sustainability. A product can impact a business in
many ways, such as revenue generation, market positioning, brand reputation, compliance and long-term growth
strategies.
Benefit to Society
In simple terms, benefits to society are the positive effects that something can have on society as a whole, such as
health, education, community, and the environment. Products that are focused on benefitting society are used to help
an organization fulfill their mission and can contribute to initiatives such as capacity building, developing partnerships,
fundraising, and building awareness.

3.3.3. How can Product Value be measured?

Teams deliver value to customers by releasing product Increments. Customers use product Increments to achieve
outcomes that they find valuable. Evidence-Based Management (EBM) expresses this value using a concept called
Current Value to refer to the outcomes that a user of a product is able to achieve today.
Current Value is important because it measures what a product can do for its users today. Each product Increment
seeks to improve the Current Value that users of the product experience.
Simple questions to find example measures of Current Value include:
• Was the product purchased or downloaded (even for evaluation purchases)?
• Is the product actually used?
• Are some features not used?
To develop more complete measures of Current Value, focus on whether the product actually helps the user to achieve
their desired outcomes. Doing this requires more qualitative measurements such as:
• Observing people using the product to see how they are using it and what they are able to achieve using it.
Observation provides the greatest amount of information about user experiences, but it can introduce biases
through observer effects that change how people behave when they know they are being observed.
Observation may also not be possible in cases where users have concerns about privacy.
• Asking people about their experiences and what they achieved, either through interviews or surveys. Surveys
can be effective, but they lag behind the user’s actual experience, and they reflect what users think they did or
Based on Scrum.org (The home of Scrum) Página 60
The Professional Scrum Competency

achieved, which may differ from what they actually did or achieved.
• Looking at lagging aggregate measures obtained through general customer satisfaction surveys. Lagging
aggregate measures like customer satisfaction surveys or Net Promoter Scores are useful in telling the product’s
producing organization that the product has some value, although the specific measures are not detailed
enough to be able to tell which aspects of the product are useful and which are not.
Whatever measurements you choose to use, they should be helpful in your context in understanding Product Value.
What is important is that you do not over-invest in looking for the most data points. Two or three measures is good
enough to get started with, and change and add or remove as your context and goals change.

3.3.4. How do you know when you’ve delivered enough Product Value?
Current Value is important because it provides people with a way to express and understand what a product does for
its users today. It is not, by itself, a measure of customer satisfaction because it does not take into account the
expectations of the user. Therefore, a product can deliver significant Current Value and yet still leave users unsatisfied.
This information is especially important in managing the life cycle of a product.
To illustrate, consider an Electric Vehicle (EV) that has an effective range of 100 miles (161 km) on a full charge. If the
EV’s driver only makes short trips, they may be completely satisfied, but if they want to take longer trips of several
hundred miles or kilometers, they will not be satisfied. The difference between the current range of the EV and the
desired range of its driver can be expressed in terms of Unrealized Value.
Unrealized Value, also referred to as a satisfaction gap, is the difference between a person’s current experience or level
of satisfaction, and their desired experience or level of satisfaction. Groups of customers with similar desired outcomes
can be considered together for planning and analysis purposes.
Unrealized Value is useful because it helps an organization understand where it may find new opportunities to deliver
value. It is also useful in product portfolio management as a way to compare different opportunities.

3.3.5. How do you know if there is more Product Value to pursue?

Unrealized Value is a subjective perception, and so measuring it generally requires interviewing or surveying users
about what they can currently achieve and what they would still like to, but cannot currently, achieve. Like measuring
Current Value, measuring Unrealized Value often relies upon:
• Observing people using the product to see how they are using it and what they are able to achieve using it, but
also asking them what they would like to achieve but they cannot. Insights often come from watching people
struggle with the product when trying to achieve some goal, or seeing them use the product in some unusual
and unexpected ways to achieve some goal.
• Asking people about their experiences and what they achieved, but also what they were not able to achieve
through interviews. Surveys may provide some insights but lack a way to ask follow-up questions when answers
differ from expectations.
For example, in the situation with Electric Vehicles (EV), through observation, we may notice that when someone is
going to run errands in their neighborhood, they would elect to drive an EV. Whereas, when asked to drive a long
distance, they choose to drive a gas car because they feel more secure about being able to drive the car a long distance.
If they run low on fuel, gas stations are widely available. Alternatively, through surveys, we could learn that potential
EV buyers would be more apt to purchase one if they could feel secure that they would not be stranded without energy
to fuel their car. This could be approached in different ways - through more mileage per charge or more charging
stations available.

3.4. Product Backlog Management

Product Backlog Management is the act of adjusting and ordering items on the Product Backlog so that the Scrum Team
can deliver the most valuable product possible. A Product Owner is accountable for managing the Product Backlog.
They do so as often as they see fit and can also delegate the responsibility to others. However, the Product Owner
ultimately decides on what work to pursue now, later or not at all.
Based on Scrum.org (The home of Scrum) Página 61
The Professional Scrum Competency

3.4.1. The Importance of Effective Product Backlog Management

Product Backlog management is an important skill that helps the Scrum Team work more effectively on their product
and deliver value. When a Product Backlog is well-managed, the Scrum Team can work on the most important items in
the order that contributes toward a shared goal and direction for the product.
On the other hand, when a Product Backlog is not
well-managed the Product Owner risks being
misaligned with team members and stakeholders.
This misalignment generally causes team members
to waste time on refining and working on Product
Backlog items that the customer does not want.
Furthermore, the Scrum Team accumulates an
overwhelming number of Product Backlog items
which makes effective Product Backlog management
nearly impossible. When the Product Backlog
becomes a long list of random ideas and tasks, it is
often referred to as a “bloated Product Backlog”.
This type of Product Backlog is difficult for the
Product Owner to order effectively, is difficult for
Developers to work from, and is hard for
stakeholders to easily understand the potential
value that customers will receive.
In order to manage the Product Backlog effectively,
the Product Owner should ensure that the backlog is
ordered appropriately and up-to-date, so that it:
• Increases transparency and the shared
understanding of the work that needs to be
done to improve the product
• Sets clear expectations with stakeholders
about what is included in the Product Backlog and what is not
• Focuses the Scrum Team’s development efforts on delivering the next most important items of value
• Aligns the team on a shared Product Goal which is a step toward the product vision
• Minimizes the time wasted focusing on items that are considered to be of low importance
Product Backlog management allows the Product Owner to work with the Developers and stakeholders to create
transparency and clarity around the Why and the What of the work that the team is pursuing to deliver value. However,
it can quickly become unproductive when the team spends a lot of time diving deep into conversation about how the
work should be done. This is because more information will emerge during the Sprint and the work may evolve. The
Scrum Team will learn how much Product Backlog management is sufficient for them and how much information they
need in order to start the work and finish it within a Sprint.

3.4.2. Product Backlog Management Activities

Product Backlog Management involves creating, refining, and ordering the Product Backlog.
The following activities are different types of work that are involved in Product Backlog Management and Refinement.
• Formulating a Product Goal
• Deciding on what to include and not include
• Ordering the Product Backlog
• Adding more information to PBIs as more information is uncovered
• Breaking down Product Backlog items
• Sizing Product Backlog items

Based on Scrum.org (The home of Scrum) Página 62

The Professional Scrum Competency

Formulating a Product Goal

Product Goals are intermediate goals that help a Scrum Team learn and progress toward their Product Vision.
When formulating a Product Goal, it should be:
• Aligned with and makes progress toward the Product Vision
• Clear and concise
• Outcome-driven to reflect a customer want or need
• Measurable
• Transparent with a shared understanding across the Scrum Team and stakeholders
Product Goal Example:
Consider the example of a company that runs a boutique dog hotel.
The boutique dog hotel’s Product Vision:
To be the premier destination for dog boarding, providing our guests with a luxurious and pampered experience that
goes beyond their owner’s expectations.
These are Product Goals that may be a step toward that vision:
• Open the first branch that can safely host up to 12 canine guests simultaneously by next summer
• Increase the number of returning canine guests by 25% within 6 months of opening our first branch
• Create a safe and secure environment where dogs can relax and play without worry
Product Goals are hypotheses that a Scrum Team uses to progress toward their Product Vision. They can change as the
team learns more about stakeholder and customer needs and help the Product Owner manage the Product Backlog.
Deciding on What to Include and not Include in the Product Backlog
An effective Product Owner ensures valuable items that improve the product and the customer experience are included
in the Product Backlog. This means they must make decisions on what should be or should not be included in the
Product Backlog. To do this well, they spend time with customers and stakeholders to learn and gather feedback from
them.
The Sprint Review is the Scrum event where stakeholders and customers offer feedback and insights to the Scrum
Team so that the team can inspect and adapt the Product Backlog. They do so by adding new Product Backlog items
and removing those that do not seem valuable enough to pursue.
To keep the Product Backlog lean and ensure development efforts are focused on the most important items, Product
Owners will need to say ‘No’ at times. Being respectful and communicating a clear message plays a big role in helping
stakeholders and customers understand why certain items should or should not be included in the Product Backlog. To
help with this Product Owners should:
• Clearly communicate the current Product Goal - Explain what they are trying to achieve with the product and
how the work on the Product Backlog should be aligned to this goal
• Be empathetic and curious - They should listen to understand why the request would be important.
• Revisit ‘old’ Product Backlog items with stakeholders to see if they’re still relevant - These are items that have
been on the Product Backlog for a while but have not been important enough to rise to the top.
• Be clear and transparent in their decision-making process - Support decisions with data such as usage data,
customer satisfaction, Current value, Unrealized value, etc.
• Know their product, customer and Product Vision
Ordering the Product Backlog
A Product Backlog contains different types of work from new feature development to defect management. The way
that a Product Owner should order these types of items is by considering the value it brings to the customer. Not every
feature needs to be built and not every defect should be fixed if they are not important to the customer. A Product
Owner orders a Product Backlog in any way they think will maximize the value of the product. They take various factors
into consideration when ordering the Product Backlog such as business value, risk, return on investment (ROI),
dependencies and impact.
Based on Scrum.org (The home of Scrum) Página 63
The Professional Scrum Competency

Breaking down Product Backlog Items

When Product Backlog items are large and complex, the Scrum Team typically finds them ambiguous and
overwhelming. Breaking down Product Backlog items or splitting them into smaller, manageable pieces of value allows
the Scrum Team to develop more of a shared understanding of what needs to be done. It also better enables the Scrum
Team to deliver at least one Done increment in each Sprint and have quicker feedback loops. This allows the Scrum
Team to consider the most important work first and increases their ability to pivot faster.
To illustrate, consider a large Product Backlog item for an e-commerce business, allowing online payments. This feature
includes the ability for a customer to pay with three different types of credit cards, online banking transfer and gift
cards. When the team breaks down this Product Backlog item, the Product Owner is in a better position to decide what
is most important to pursue first and can order how they see best fit. For example, since most of their customers use
credit cards to pay, the product should likely offer the ability to pay by credit card first. This approach of pursuing
smaller pieces of work allows for quicker learning and ensures that the most valuable aspects of the product are
developed earlier.
Sizing Product Backlog Items
As Developers are the ones who need to do the work, they are the people who are responsible for the sizing of the
work. There are various techniques teams may use to size their Product Backlog items such as:
• Absolute - often time-based; for example, “This PBI will take 9 hours of work”
• Relative - uses a scale that lets developers estimate the size of the PBIs relative to each other; for example,
story points or t-shirt sizing
• Right sizing - identifies items that are small enough to be completed within one single Sprint; for example,
Developers discuss if they can complete a PBI according to their Definition of Done comfortably within one
Sprint, if not they should break down the PBI
The Developers should choose whichever sizing method makes most sense for them as a team.

3.4.3. Tips for Effective Product Backlog Management

For Product Backlog management to be effective, consider these following tips:
• Review, reorder and refine the Product Backlog frequently
The Product Backlog is emergent; it evolves and changes. Feedback, learnings from experiments and changing market
conditions are just a few factors that influence changes within a Scrum Team’s Product Backlog. Reviewing and
reordering it frequently helps the team focus on the next important items to pursue.
• Keep the Product Backlog manageable
When a Product Backlog grows too big, it becomes hard for the Scrum Team and stakeholders to decipher what is
important to pursue. Furthermore, it becomes a useless communication tool and wasteful to manage and refine. To
create a more manageable Product Backlog, the Product Owner should make choices about what should NOT be on
the list in a respectful but clear manner.
• Visualize the Product Backlog
Visualizing the Product Backlog helps a Scrum Team and its stakeholders see what work is next, allowing them to think
ahead. This usually triggers relevant discussions and develops a shared understanding of what is needed to improve
the product.
A Scrum Team should visualize their Product Backlog somewhere that is easily accessible to all, including stakeholders,
whether it is on a physical wall or in a virtual tool. The Scrum Team should choose a tool that works for them in their
context but ultimately that optimizes for transparency.
• Take a collaborative approach
Although a Product Owner is accountable for managing the Product Backlog, they do not need to do it alone. In fact,
collaborating with the rest of the Scrum Team, stakeholders and customers, helps a Product Owner make better and
more informed decisions when managing the Product Backlog.

Based on Scrum.org (The home of Scrum) Página 64

The Professional Scrum Competency

• Don’t jump straight to solutions

Product Owners constantly focus on what their customers need and what challenges there are to solve for them. That
focus creates ideas to enhance a customer’s experience of the product. However, Product Owners should resist rushing
into solutions and adding those ideas straight into the Product Backlog.
A Product Owner should work with the team and give the Developers on the team the problem to solve. This is a good
way to leverage different experiences, expertise and perspectives. This enables the Developers to come up with
innovative and creative ideas on how to solve the problem and helps them develop ownership of the product.

3.5. Business Strategy

An organization’s Mission Statement expresses the organization’s purpose and defines why the organization exists. It
focuses on what the organization is today.
An organization’s Vision Statement expresses the long-term aspirations of the company and what it hopes to achieve
in the future. It does not say how it will achieve the vision.
Senior executives in an organization are typically accountable for creating the organization’s mission and vision. These
drive an organization's business strategy.
A business strategy is a company or organization’s plan for how it will achieve its long-term goals and objectives. It
outlines and provides guidance for the strategic initiatives an organization will pursue to create value for the
organization and its stakeholders.
The business strategy is informed by the company’s mission and vision, and in turn informs individual product visions.
An organization inspects and adapts its business strategy based on feedback gathered from delivering product
Increments.

The relationship between Mission/Vision, Business Strategy, Product Vision, and Product Strategy
The business strategy typically includes:
• Strategic goals and objectives for the organization as a whole
• The markets and customers that the organization should target with its products
• The value proposition that the organization has for its customers, employees and partners
• The investment the organization is willing to make in support of its objectives
• The stage a product is in its life cycle
Senior executives in an organization are typically accountable for creating the organization’s business strategy. The
content and format of the business strategy varies from organization to organization and is highly context dependent.
Some organizations engage in rigorous planning, resulting in detailed information. Whereas, other organizations do
not appear to engage in any strategic planning. The planning context is very different in a large organization with a
Based on Scrum.org (The home of Scrum) Página 65
The Professional Scrum Competency

broad product portfolio than in a smaller, one-product company. In fact, a one-product company probably doesn’t
need both a company business strategy and a product strategy.

3.5.1. Scrum and Business Strategy

Although the concept of a “business strategy” is not mentioned in the Scrum Guide, it provides vital context that helps
the organization define products and their goals.

The relationship between Mission/Vision, Business Strategy, Product Vision, Product Strategy, and Product Goals
Product Owners use the business strategy as guidance to their product planning activities. From the business strategy,
they craft a product vision and product strategy for each of the products in the company’s portfolio. From this, they
set the first Product Goal and the team creates a Product Backlog to fulfill it.
Establishing a business strategy is a complex problem that requires an empirical approach. The business strategy should
be continually adapted as more is learned. Ideally, the business strategy should outline several experiments for
validating assumptions that are made in the strategy. For example, experiments to:
• Investigate a hypothesis that a flattened organizational structure will help deliver value
• Validate that a new market segment is worthy of investment
• Understand whether the use of new technology would be viable and worth the necessary expenditure
An agile approach to strategic planning is to support the self-management of product teams by providing clear goals,
boundaries and accountabilities. This can be done by performing just enough business strategy planning to provide the
guidance that product leaders need to make decisions and formulate the company’s product or product portfolio.

3.5.2. Evidence-Based Management (EBM) and Business Strategy

Evidence-Based Management (EBM) is an empirical approach that helps organizations to continuously improve
customer outcomes, organizational capabilities, and business results. Central to EBM is the notion that using
intentional experimentation and evidence will enable organizations to systematically improve their performance and
refine their goals based on better information.
The Business Strategy defines, at minimum, the Strategic Goals for the organization. It may go further and also define
Intermediate Goals for the organization if the Strategic Goal is so lofty and its achievement so far into the future that
the organization needs nearer-term goals to guide its decisions.
The organization makes progress toward its goals when Scrum Teams deliver products to customers, measure the
result, and then assess the results against their Product Goals. Collectively, the progress that all teams make toward
their Product Goals should move the organization closer to achieving its goals. If it does not, the goals should be re-
evaluated.
The “experiment loop” shown in the following diagram represents, collectively, all the Sprints in which Scrum Teams
develop and deliver valuable product Increments.
The experimentation and feedback loops that impact the business strategy can happen on many levels within an
organization. For example, they can be on the:

Based on Scrum.org (The home of Scrum) Página 66

The Professional Scrum Competency

• Organizational level. For example,

when moving from a project to product
delivery model, there may be
experiments related to the
organizational structure. The results
might impact the product portfolio and
products
• Portfolio level. For example, an
organization may want to validate
whether expanding to new markets is
the right thing to do. The findings from
these experiments may impact the
business strategy.
• Product levels. Scrum Teams regularly
create experiments to understand if
their work is closing the customers’
satisfaction gaps (for instance, reducing
our customers' anxiety regarding
security issues). The Scrum Teams’
findings and Increments as well as
stakeholder feedback and input might
impact a Business Strategy and often
redefine Strategic Goals
In this way, all levels are constantly connected and influence each other through validation results, ongoing feedback
and market changes.
A Strategic Goal might be easier to define (or refine) by
focusing on Unrealized Value (potential, opportunities, gaps
and desired outcomes) on the product, product portfolio and
organizational level, Also, having current and relevant data
from all 4 EBM Key Value Areas in respective products might
enhance the organizational perspective, thus influencing a
business strategy and product portfolio decisions.
• Unrealized Value (UV): Potential value
• Current Value (CV): Value delivered today
• Ability to Innovate (A2I): Effectiveness to deliver new
capabilities to meet customer needs
• Time to Market (T2M): Ability to quickly deliver new
capabilities to meet customer needs

3.6. Stakeholders
Anyone who is impacted by the outcome of the product and is interested in its success is considered a stakeholder.
Examples of a Scrum Team’s stakeholders may include:
• Customers - users and buyers of the product
• Internal stakeholders - company management and other organizations such as Human Resources/Talent
Management, compliance, finance, etc.
• Partners - suppliers, vendors and other business partners
• Influencers - external influencers such as trade organizations, media or industry analysts
Engaging with stakeholders is central to the success of any kind of product development. Only they can provide the
feedback necessary to ensure that the product satisfies their needs and expectations.
Based on Scrum.org (The home of Scrum) Página 67
The Professional Scrum Competency

3.6.1. Identify and Learn about Key Stakeholders

While it’s important to understand who all of the Scrum Team’s stakeholders might be, not all stakeholders must be
treated in the same way. Scrum Teams should engage with stakeholders in the ways appropriate for getting the
feedback they need. For example, some of the stakeholders should regularly engage with the Scrum Team using Scrum
artifacts and Scrum events, but others may cause a distraction. All stakeholders are important, but only key
stakeholders are invited to participate in Scrum events and artifacts.
Here are different ways Scrum Teams can try to understand who their key stakeholders are and how to engage with
them:
• Engage in a Stakeholder Mapping activity to better understand who their stakeholders are
• Create a Stakeholder Engagement Approach to engage the right people at the right time to maximize the value
of the product
• Learn and use techniques to better understand their customers and their customers’ needs

3.6.2. Common Challenges in Stakeholder Engagement

Here are some common challenges Scrum Teams face when engaging with stakeholders and ways to overcome these
challenges:
Stakeholders don’t come or participate fully in the Sprint Review
How to overcome this challenge
• Frequent, iterative stakeholder feedback is a critical part of Scrum. This feedback helps:
• Keep the concept of creating customer value top-of-mind for the Scrum Team
• Validate the assumptions that the Scrum Team made about user needs and any tradeoffs they made during the
Sprint
• Reduce risk by uncovering issues or problems early and often
• Limit the likelihood that the Scrum Team goes in the wrong direction while trying to solve customer problems
When stakeholders don’t participate in Sprint Reviews, the entire Scrum Team, especially the Product Owner, should
ask for stakeholder input in order to improve the product.
Stakeholders don’t understand their roles and responsibilities while engaging with the Scrum
Team
How to overcome this challenge
If this is the case, help improve the stakeholders' understanding of Scrum and its empirical nature by helping them to
realize the importance that they play in delivering better products to market. At the same time, the Scrum Team needs
to understand that the Sprint Review is not their only time to get stakeholder input. They can engage and learn as
needed to help refine Product Backlog items and capture more detailed expectations. Building a stronger relationship
between the Scrum Team and stakeholders overall can help to drive long-term collaboration. At least for the first few
Sprint Reviews, start by explaining the goal of a Sprint Review and the important role that everyone plays in it.
Stakeholders demand that their PBI be added or ordered higher in the Product Backlog
How to overcome this challenge
The Product Owner is accountable for Product Backlog management, including ordering the Product Backlog items
(PBIs). Centralizing this accountability on one person increases focus, streamlines decision-making and increases the
likelihood that the most valuable feedback, rather than the ideas of the most forceful stakeholders, are taken into
account.
Scrum entrusts this accountability to the Product Owner and it’s the Product Owner’s responsibility to push back on
forceful stakeholders as needed. Saying “no'' may be difficult, but necessary in certain situations. This disagreement
on priorities also opens an opportunity for the Product Owner to have a conversation around how the suggestion
supports the Product Goal. When stakeholders are uncompromising and insist that their suggestion is what customers
want, the Product Owner must learn more about the root of the stakeholder’s insistence and determine for themselves

Based on Scrum.org (The home of Scrum) Página 68

The Professional Scrum Competency

whether the suggestion has merit.

Stakeholders ask for a concrete release date with a list of features that will be included at that time
How to overcome this challenge
It’s not surprising that stakeholders are eager to receive the product and want to know when to expect it. However,
when solving complex problems using an empirical process, we are iteratively building our way to the solution, learning
along the way and don’t know precisely when we’ll be done. We simply don’t have all the answers yet! That said, it’s
possible to help the stakeholders feel more comfortable by reminding them that Scrum focuses on delivering customer
value early and often, has well-defined goals and provides the opportunity for them to inspect progress during the
Sprint Reviews.
In addition, it’s possible to help them visualize the progress being made by sharing forecasts and a product roadmap.
It must be made clear that the only thing the Scrum Team can provide is an estimate, since they do not know what
issues or feedback they may encounter as they do their work.

Based on Scrum.org (The home of Scrum) Página 69

The Professional Scrum Competency

4. Developing and Delivering Products Professionally

Developing and Delivering Products Professionally with Scrum results in high-quality products delivered iteratively and
incrementally with relatively high frequency. These products meet the needs of stakeholders and customers and
provide flexibility for both early value realization and adaptation to changing needs. Professional software
development requires collaboration among team members and the entire organization, and there are a set of Focus
Areas that, when understood and applied, yield the holistic realization of this end-to-end-vision.
Management throughout the lifespan of development, reducing cycle times, and eliminating waste requires a proven
set of tools and processes that help organizations integrate different teams, platforms, and activities. The Focus Area,
Continuous Integration and Continuous Delivery, provides a set of practices and techniques to deliver value
continuously, marrying the ideas of frequent learning with the concepts of small batch size and automation.
The Scrum Team(s) use an Emergent Software Development approach for the overall structure definition, where the
specific detailed design decisions are made when needed, but not before. The detailed decisions build on the overall
framework to create a coherent product that meets organizational standards.
Scrum Teams should also focus on Optimizing Flow and Continuous Quality that consistently delivers fully integrated,
tested, and potentially releasable “Done” product increments every Sprint. Incorporating the appropriate engineering
practices and tools will help facilitate the consistent development of integrated "Done" increments while Managing
Technical Risk that could otherwise compromise the team’s ability to quickly and easily adapt the product to changing
needs, thereby hindering the organization's agility.
The Scrum Team(s) are naturally the tangible developers of Professional Software but some proficiency with
Developing and Delivering Product Professionally is important for all roles within an organization to facilitate
communication, collaboration, and stakeholder participation.
Within each competency, a number of Focus Areas provide a more detailed view of the knowledge and skills you
require to master that competency.

1. Emergent Software Development

In solving complex problems, the idea of a detailed up-front design has been replaced with an approach that
encourages design to emerge and change within the boundaries of an architecture. In this Focus Area, practitioners
will be able to describe what emergent architecture is and how it translates into incremental development and delivery.
They will be able to describe practices that “realize” the architecture incrementally into a working, agile system.
Practitioners will understand the trade-offs between value, flexibility, and quality, and will also be able to apply
techniques that make the emergent approach transparent to the team, organization, and stakeholders.

2. Managing Technical Risk

All products have an inherent set of risks to manage. These risks range from the ability to deliver to technical risks
associated with performance and security. This Focus Area describes how technical risks are managed within an Agile
approach. Practitioners should understand what technical risks are and how to effectively manage them in an empirical
process. They should also understand how to apply practices to make risks transparent.

3. Continuous Quality
Working in an agile way does not change the importance of product quality. It does, however, change when and where
quality is addressed. This Focus Area describes what quality is and how the ideas of Agility and Scrum change a
product's quality approach. The practitioner will understand what continuous quality is, how to apply it, and the
appropriate practices for delivering quality in a continuous way. They will understand important concepts like technical
debt, Test Left, and the ideas of user-driven testing.

4. Continuous Integration (CI) / Continuous Delivery (CD)

Frequent learning is a fundamental concept for Scrum. Continuous Delivery and Continuous Integration are a key
collection of practices that enable frequent observation of working features. This Focus Area describes the value of the
Based on Scrum.org (The home of Scrum) Página 70
The Professional Scrum Competency

core idea that code should always be deployable and an understanding of the techniques that can be employed for
delivering software that solves complex problems. The practitioner will understand what CI and CD are, how to apply
these ideas, and what it means for an empirical process and the Scrum framework.

5. Optimizing Flow
The Sprint is a time-box with clear flows within it. For large, complex work, the Sprint is just a small part of a broader
flow for the product, business, or even market. This Focus Area concentrates on making flow transparent and ensuring
that waste is reduced or removed. Automation and measurement are key elements to ensuring flow efficiency, coupled
with a series of rules that have evolved in response to improving flow. The practitioner will be able to look to flow
approaches such as Kanban and integrate these ideas with Scrum, frequently delivering valuable products and learning.

Based on Scrum.org (The home of Scrum) Página 71

The Professional Scrum Competency

5. Evolving the Agile Organization

Organizations need to learn fast and respond quickly to market conditions in the Digital Age. Evolving the Agile
Organization includes concepts and tools for measuring and enabling business agility through Evidence-Based
Management (EBM). It also examines the importance of Organizational Design and Culture, which includes human
factors, processes, and structures in the organization that can promote or inhibit agility with Scrum.
Evidence-Based Management (EBM) encourages rational, data-driven decisions while applying empirical process
theory to the development of high-value products. EBM provides a set of perspectives on value and the organization’s
ability to deliver value. These perspectives are called Key Value Areas (KVAs). These areas examine the goals of the
organization (Unrealized Value), the current state of the organization relative to those goals (Current Value), the
responsiveness of the organization in delivering value (Time-to-Market), and the effectiveness of the organization in
delivering value (Ability-to-Innovate). Focusing on these four dimensions enables organizations to better understand
where they are and where they need to go Organizational Design and Culture focuses on understanding how
organizational attributes affect strategy, stimulate employees, and build distinctive capabilities that make it easier, or
harder, to deliver value to customers. Organizational design, and the use of tools that can help guide iterative and
incremental value-focused organizational change, are critical to evolving and cultivating an Agile culture.
Additionally, Scrum uses empiricism and self-organization to address Portfolio Planning. It is important to recognize
that this approach affects the entire organization, not just the Agile Leaders, Scrum Masters, Product Owners, and
Developers. Every person who has inputs to, or outputs from, a Scrum Team or Teams is affected by how the team
works within the organization.
Scrum Masters and Agile Leaders are particularly attentive to Evolving the Agile Organization, but a key element to
that growth is for all roles in the organization to understand the growth vision, hence, this competency applies to all
roles.
Within each competency, a number of Focus Areas provide a more detailed view of the knowledge and skills you
require to master that competency.

1. Organizational Design and Culture

Traditional organizations are often structured around Taylorism and mass production concepts in response to simple
problems. Complex problems require a different way of organizing. This Focus Area describes the fundamental
differences of an agile organization; namely its structure, culture, and design. A practitioner will understand what an
agile enterprise looks like and approaches for implementing the agile enterprise in a traditional organization. They will
understand how to balance the needs for agility with the existing reality of traditional organizational structures.

2. Portfolio Planning
For many large organizations, work is being undertaken in the context of a broader portfolio. That portfolio could be a
product, system, value stream, supply chain, or even a program. This Focus Area describes what agile portfolio planning
looks like; its characteristics, principles, and associated practices. The Practitioner will understand why agile portfolio
planning must be different than traditional portfolio planning in order to deal with complex products and systems.
They will also understand how to apply these ideas to their portfolio. Practitioners will understand the challenges of
managing complex dependencies and the choices that need to be made, while ensuring that team agility is not broken,
to serve the needs of the larger organization.

3. Evidence-Based Management
A fundamental element of Scrum is empirical process; the idea that complex problems require real experience to
effectively plan and deliver value. Evidence-Based Management (EBM) is a set of ideas and practices that describe
broad measurement areas used to provide an effective, empirical, and value-based approach to any product. This Focus
Area describes what EBM is and how to apply it to any product. The practitioner will understand what EBM is, as well
as the practices that comprise it, and how to use EBM to enable a business-driven, value-based empirical process.

Based on Scrum.org (The home of Scrum) Página 72