Product Owner Guide V1.

0 2024

www.europeanscrum.org
Table of Contents
1 Introduction. ...................................................................................................... - 4 -
1.1 Objective of the Guide ...................................................................................................... - 4 -
1.2 Definition of the Product Owner Role .............................................................................. - 4 -
1.3 Importance of the Product Owner in Scrum ..................................................................... - 4 -
2 Scrum Framework .............................................................................................. - 5 -
3 Rules .................................................................................................................. - 5 -
4 Events ................................................................................................................ - 5 -
4.1 Sprint................................................................................................................................. - 5 -
4.2 Sprint Planning .................................................................................................................. - 6 -
4.3 Daily Scrum ....................................................................................................................... - 6 -
4.4 Sprint Review .................................................................................................................... - 6 -
4.5 Sprint Retrospective ......................................................................................................... - 6 -
4.6 Refinement (or Grooming)................................................................................................ - 7 -
5 Scrum Team ....................................................................................................... - 7 -
5.1 Scrum Master.................................................................................................................... - 7 -
5.2 Product Owner .................................................................................................................. - 8 -
5.3 Development Team .......................................................................................................... - 8 -
6 Increment .......................................................................................................... - 8 -
7 Product Backlog ................................................................................................. - 9 -
8 Sprint Backlog .................................................................................................... - 9 -
9 Roles and Responsibilities of a Product Owner ................................................. - 10 -
9.1 Roles ............................................................................................................................... - 10 -
9.2 Responsibilities ............................................................................................................... - 11 -
10 Artifacts for Defining the Product by the Product Owner .................................. - 12 -
10.1 Empathy Map.................................................................................................................. - 12 -
10.2 Persona Map ................................................................................................................... - 12 -
10.3 Shadowing ...................................................................................................................... - 12 -
10.4 Business Canvas .............................................................................................................. - 13 -
10.5 Product Canvas ............................................................................................................... - 13 -
10.6 Product Elevator Pitch .................................................................................................... - 13 -
10.7 Story Mapping / Scrum Skeleton .................................................................................... - 13 -
11 General Relationship with the Scrum Product Owner ....................................... - 14 -
11.1 Product Vision Definition ................................................................................................ - 14 -
11.2 Expected Characteristics and Qualities ........................................................................... - 14 -

-1-
www.europeanscrum.org
 11.3 Techniques for Crafting a Vision and Mission ................................................................. - 14 -
11.4 Relationship Between Vision and Product Roadmap...................................................... - 15 -
11.5 Techniques for Listening to and Understanding the Customer – Socratic Questioning . - 15 -
11.6 Building and Prioritizing the Roadmap / Product Backlog .............................................. - 15 -
12 The Product Owner and Sprint 0 ....................................................................... - 15 -
12.1 Dynamic Product Backlog Management ......................................................................... - 16 -
13 Types of Contracts in Agile/Scrum .................................................................... - 16 -
13.1 Client Expectations ......................................................................................................... - 16 -
13.2 How It's Handled in Agile/Scrum .................................................................................... - 17 -
13.3 Different Contract Types ................................................................................................. - 17 -
13.4 Time & Material, Fixed Price, Fixed Scope, Cost Ceiling ................................................. - 17 -
13.5 Phased Development ...................................................................................................... - 17 -
13.6 Bonus/Penalty Clauses .................................................................................................... - 18 -
13.7 Money for Nothing / Changes for Free ........................................................................... - 18 -
13.8 Summary of the Product Owner's Relationship with Contract Types ............................. - 18 -
14 Product/Project Scope (Product Backlog) ......................................................... - 19 -
14.1 What the Product Backlog Is and Is Not ......................................................................... - 19 -
14.2 Prioritization Criteria....................................................................................................... - 19 -
14.3 Prioritizing the Product Backlog, Releases, and Sprints .................................................. - 19 -
14.4 Business Critical / Nice to Have, MoSCoW, Kano Model, Pareto Principle ..................... - 19 -
14.5 Refining Scope and Continuous Planning ....................................................................... - 20 -
14.6 Scope Prioritization (Business Critical & Nice to Have) ................................................... - 20 -
14.7 Project, Releases, and Sprint Completion Criteria – Definition of Done (DoD) .............. - 20 -
14.8 Relationship of the Product Owner with These Concepts .............................................. - 20 -
15 Story Mapping and Scrum Board ...................................................................... - 21 -
15.1 Story Mapping................................................................................................................. - 21 -
15.2 Scrum Board.................................................................................................................... - 21 -
15.3 Relationship Between Story Mapping and Scrum Board from the Product Owner's
Perspective .................................................................................................................................. - 22 -
16 Decomposition in Scrum ................................................................................... - 23 -
16.1 Themes, Epics, User Stories, and Tasks........................................................................... - 23 -
16.2 What is a User Story? ...................................................................................................... - 23 -
16.3 Grammar of User Stories ................................................................................................ - 23 -
17 Definition of Sprints ......................................................................................... - 23 -
17.1 Who Defines Sprints?...................................................................................................... - 23 -
17.2 Fixed or Variable Length? ............................................................................................... - 24 -

-2-
www.europeanscrum.org
 17.3 Relationship Between Sprints, Releases, MVP, and MMP .............................................. - 24 -
17.4 Sprint Goal ...................................................................................................................... - 24 -
17.5 Definition of Done (DoD) ................................................................................................ - 24 -
17.6 Validation and Sprint Review .......................................................................................... - 24 -
17.7 Relationship Between Decomposition and Sprints from the Product Owner’s Perspective . -
25 -
18 Change Management 3.0 in Scrum ................................................................... - 25 -
18.1 Change Management with Clients, Scrum Teams, and Contracts .................................. - 25 -
18.2 Grooming/Refinement .................................................................................................... - 26 -
18.3 Contingency Reserve ...................................................................................................... - 26 -
18.4 Decision-Making Analysis ............................................................................................... - 26 -
18.5 Evolutionary and Iterative Development – Releases/Sprints ......................................... - 26 -
18.6 Relationship with the Product Owner............................................................................. - 27 -
19 Relationship Between Scrum and Design Thinking............................................ - 27 -
19.1 User-Centric Focus .......................................................................................................... - 27 -
19.2 Iteration and Incremental Development ........................................................................ - 27 -
19.3 Collaboration and Cross-Functional Teams .................................................................... - 28 -
19.4 Problem-Solving Approach ............................................................................................. - 28 -
19.5 Implementation from the Product Owner’s Perspective ................................................ - 28 -
19.6 Benefits of Integration .................................................................................................... - 28 -
19.7 Conclusion....................................................................................................................... - 29 -
20 Relationship Between Scrum, Kanban, and Lean from the Product Owner's
Perspective .................................................................................................................. - 29 -
20.1 Scrum from the Product Owner's Perspective ................................................................ - 29 -
20.2 Kanban ............................................................................................................................ - 29 -
20.3 Lean................................................................................................................................. - 29 -
20.4 Relationship Between Scrum and Kanban ...................................................................... - 30 -
20.5 Relationship Between Scrum and Lean .......................................................................... - 30 -
20.6 Conclusion ...................................................................................................................... - 30 -
21 Implementation from the Product Owner's Perspective .................................... - 31 -
21.1 Integration of Kanban into the Scrum Process ............................................................... - 31 -
21.2 Integration of Lean into the Scrum Process .................................................................... - 31 -
21.3 Benefits of Integration .................................................................................................... - 31 -
21.4 Conclusion....................................................................................................................... - 32 -
22 Best Practices of a Good Product Owner ........................................................... - 32 -
23 Acknowledgments. ........................................................................................... - 33 -

-3-
www.europeanscrum.org
1 Introduction.

1.1 Objective of the Guide

In today's dynamic and competitive business world, agility is not just an advantage; it is a
necessity. Organizations are constantly seeking ways to adapt quickly to market changes,
and Scrum has emerged as one of the most effective frameworks for managing projects and
other types of creative work. At the heart of Scrum lies the Product Owner, a key figure who
acts as the bridge between business needs and the development team.

This guide is designed to provide a deep understanding of the Product Owner role, its
responsibilities, and the competencies needed to perform it successfully. We will explore
how this role can influence the creation of valuable products, the effective prioritization of
tasks, and the maximization of value delivered to the customer.

The Product Owner not only defines and communicates the product vision but is also
responsible for maintaining and prioritizing the product backlog, ensuring that the team
remains focused on the most important tasks aligned with strategic goals. Through
interviews with experts, case studies, and practical examples, this guide will offer a clear
roadmap for those looking to excel in this crucial role.

Whether you are an experienced professional in agility or someone just beginning your
journey in the world of Scrum, this guide will provide you with the tools and knowledge
needed to become an effective and successful Product Owner. Prepare to explore best
practices, tackle common challenges, and discover strategies that have led many to success
in product management. Welcome to your new stage as a Product Owner.

1.2 Definition of the Product Owner Role

The Product Owner is responsible for defining and communicating the product vision to the
entire Scrum team and stakeholders. This vision must align with the organization's strategic
objectives and reflect market and customer needs.

1.3 Importance of the Product Owner in Scrum

The Product Owner is crucial in Scrum because they define and communicate the product
vision, ensuring the development team works on the highest-value tasks. They manage and
prioritize the product backlog to maximize its value. Acting as the liaison between
stakeholders and the development team, the Product Owner ensures that business
expectations are reflected in the work. Their decision-making directly influences the success
and alignment of the product with the organization's strategic objectives.

-4-
www.europeanscrum.org
2 Scrum Framework
Scrum is an agile framework used to manage complex projects, especially in software
development. It is based on iterative cycles called sprints, which typically last between one
and four weeks, during which a product increment is planned, developed, and reviewed.
Scrum promotes collaboration, flexibility, and continuous improvement through defined
roles (Scrum Master, Product Owner, and Development Team), structured events, and clear
artifacts. Its goal is to deliver high-quality products that meet customer needs quickly and
efficiently.

3 Rules
The rules of Scrum are designed to structure and guide the work of the Scrum team. These
include:

0. Roles: Scrum defines three essential roles: the Product Owner, the Scrum Master, and
the Development Team.
1. Events: Scrum establishes five key events: the Sprint (a fixed work cycle), Sprint Planning,
the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
2. Artifacts: Scrum uses three main artifacts: the Product Backlog (a prioritized list of tasks),
the Sprint Backlog (tasks selected for the sprint), and the Increment (the result of the
completed work during the sprint).
3. Rules: Scrum’s rules are based on transparency, inspection, and adaptation. Progress and
work must be visible to all, and adjustments should be made based on results and
feedback.
4. Commitments: Each artifact has an associated commitment to ensure clarity and focus:
the Product Vision for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the
Definition of Done for the Increment.

4 Events
In Scrum, an event is a structured meeting held at specific moments during the sprint to
ensure transparency, inspection, and adaptation of the work. These events are fundamental
to maintaining the team's rhythm and cohesion, allowing them to review progress, plan
upcoming activities, and continuously improve. Scrum events include Sprint Planning, the
Daily Scrum, the Sprint Review, and the Sprint Retrospective. Each event has a clear purpose
and a defined set of participants, facilitating effective communication and collaboration
within the Scrum team.

4.1 Sprint

• Definition: A Sprint is a fixed work cycle, typically lasting one to four weeks, during
which the development team works to complete a product increment. Sprints in
Scrum can last 1, 2, 3, or 4 weeks, and the length of the sprint cannot be changed
during the project. The decision on the sprint length is made collectively by the
entire Scrum Team. Sprints can be grouped into MVPs (Minimum Viable Products),

-5-
www.europeanscrum.org
 which are trial versions to validate hypotheses, models, or prototypes, and MMPs
(Minimum Marketable Products), which are final versions that may or may not be the
definitive product.
• Participation of the Product Owner: Yes, indirectly participates.
• Role of the Product Owner: Defines the vision and priorities for the sprint, ensuring
the team focuses on the most valuable tasks.

4.2 Sprint Planning

• Definition: A meeting held at the beginning of the sprint where the team plans the
work to be done during the sprint. It is divided into two parts: the first part defines
the sprint goal and what will be done, and the second part defines how it will be
done or implemented. If the sprint is one month long, the maximum duration is 8
hours. For shorter sprints, the duration is proportional; for example, if the sprint
lasts one week, the Sprint Planning meeting lasts a maximum of 2 hours.
• Participation of the Product Owner: Yes, actively participates.
• Role of the Product Owner: Communicates the sprint vision and goals, prioritizes
and clarifies items from the Product Backlog, and collaborates with the team to
establish the sprint goal.

4.3 Daily Scrum

• Definition: A daily meeting lasting no more than 15 minutes, where the

development team reviews progress toward the sprint goal and adjusts their work
plan for the next 24 hours. Regardless of the sprint length, the duration of this event
remains the same.
• Participation of the Product Owner: Optional, not mandatory.
• Role of the Product Owner: If attending, they act as an observer to understand
progress and impediments but do not actively intervene in the meeting.

4.4 Sprint Review

• Definition: A meeting held at the end of the sprint where the team presents the
completed increment to the stakeholders and receives feedback. If the sprint lasts
one month, the maximum duration is 4 hours, with shorter sprints having
proportional durations.
• Participation of the Product Owner: Yes, actively participates.
• Role of the Product Owner: Presents the status of the Product Backlog, collaborates
in demonstrating the increment, and collects feedback from stakeholders for future
priorities.

4.5 Sprint Retrospective

• Definition: A meeting held after the Sprint Review where the team reflects on the
completed sprint and discusses process improvements. If the sprint lasts one month,
the maximum duration is 3 hours, and for shorter sprints, the duration is
proportional.

-6-
www.europeanscrum.org
 • Participation of the Product Owner: Optional, but recommended.
• Role of the Product Owner: If participating, provides insights on how to improve
collaboration and the process, but the main focus is on the development team and
the Scrum Master.

4.6 Refinement (or Grooming)

• Definition: Periodic sessions (not formal Scrum events) where the team reviews and
refines Product Backlog items for future sprints. The duration is between 5%-10% of
the total sprint length. If the sprint lasts one month, the maximum duration is
between 8 and 16 hours, with shorter sprints having proportional durations.
Refinement can be divided into multiple sessions during the sprint.
• Participation of the Product Owner: Yes, actively participates.
• Role of the Product Owner: Leads the refinement of Product Backlog items, ensures
they are clear and well-defined, and prioritizes future work based on product value
and vision.

5 Scrum Team
• Definition: The Scrum Team is a group of professionals who work collaboratively in
sprints to deliver product increments. It is self-organizing and cross-functional,
composed of the Product Owner, the Scrum Master, and the Development Team.
• Responsibility: The entire team is collectively responsible for all activities related to
product development, from planning to delivery.
• Relationship with the Product Owner: The Product Owner is an integral member of
the Scrum Team, guiding the product vision and ensuring that the team's work is
aligned with business priorities.

5.1 Scrum Master

• Definition: The Scrum Master is the facilitator of the Scrum Team and acts as a
servant-leader, helping everyone understand and properly apply Scrum.
• Responsibilities:
o Facilitate: Organizes and facilitates Scrum events.
o Remove obstacles: Helps the team overcome impediments that hinder
progress.
o Promote Scrum: Ensures Scrum is well understood and properly applied
within the team and organization.
o Coaching: Supports the Product Owner and Development Team in their roles,
promoting self-organization and continuous improvement.
• Relationship with the Product Owner: The Scrum Master supports the Product
Owner by providing tools and techniques for effective Product Backlog management
and ensuring smooth communication with the development team.

-7-
www.europeanscrum.org
5.2 Product Owner

• Definition: The Product Owner is responsible for maximizing the value of the
product resulting from the work of the Scrum Team. They act as the liaison between
stakeholders and the development team.
• Responsibilities:
o Product Backlog management: Create, prioritize, and maintain the Product
Backlog.
o Product vision: Define and communicate the product vision and objectives.
o Stakeholders: Engage with stakeholders to understand and manage their
expectations and needs.
o Decision-making: Make decisions about product functionality and priorities
to maximize its value.
• Relationship with the Scrum Master: The Product Owner works closely with the
Scrum Master to ensure that Scrum principles are effectively implemented and that
Scrum events are productive.
• Relationship with the Development Team: The Product Owner works directly with
the Development Team to clarify requirements, prioritize tasks, and ensure that the
work aligns with product goals.

5.3 Development Team

• Definition: The Development Team is a group of professionals who work together to

deliver product increments that meet the Definition of Done in each sprint.
• Responsibilities:
o Self-organization: Organize and manage their own work without external
supervision.
o Cross-functionality: Possess all the skills necessary to complete the sprint's
work.
o Product quality: Ensure that the product increment is of high quality and
meets established requirements.
o Transparency: Make sprint progress visible through Scrum tools and
practices.
• Relationship with the Product Owner: The Development Team collaborates closely
with the Product Owner to understand Product Backlog priorities, receive
continuous feedback, and adjust their work to maximize the product’s value.

6 Increment
An increment in Scrum is the sum of all Product Backlog items completed during a sprint,
along with all increments from previous sprints. It represents a step toward the product
goal, delivering tangible and potentially deployable functionality. Each increment must
meet the Definition of Done, ensuring that it is ready for use and of high quality.

-8-
www.europeanscrum.org
7 Product Backlog
• What is it? The Product Backlog is a prioritized list of all the work necessary to
develop and improve the product. It serves as the single source of requirements for
any changes to be made to the product.
• How is it Prioritized? The Product Owner is responsible for prioritizing the items in
the Product Backlog. Prioritization is based on several factors, including business
value, customer needs, risk, dependencies between items, and alignment with the
organization's strategic objectives.
• Who Builds It? The Product Owner is primarily responsible for creating and
maintaining the Product Backlog. This involves identifying and defining backlog items
based on feedback from stakeholders, the development team, and their own
product vision.
• What Does It Include? The Product Backlog consists of items or elements that may
include new features, improvements, bug fixes, technical tasks, and any other work
required to achieve the product goal. Each backlog item should have a clear
description, acceptance criteria, and an estimated value in terms of effort and
priority.
• Who Updates It? The Product Owner is responsible for continuously maintaining the
Product Backlog. However, the development team and stakeholders can also
contribute new ideas and feedback, which the Product Owner considers and
prioritizes as appropriate.
• Continuous Update: The Product Backlog is a dynamic artifact that changes
constantly as new insights about the product and the market are gained. The
Product Owner regularly reviews and adjusts the backlog to ensure it remains
aligned with strategic objectives and current priorities.

In summary, the Product Backlog is the Product Owner's primary tool for managing work
and maximizing product value. It is a living artifact that evolves over time to reflect the
business’s needs and priorities.

8 Sprint Backlog
• What is it? The Sprint Backlog is a set of Product Backlog items selected during
Sprint Planning to be worked on during a specific sprint, along with a detailed plan to
deliver the product increment. It represents the work that the development team
commits to completing during the sprint. Typically, it consists of tasks that are
breakdowns of User Stories.
• How is it Prioritized? The items in the Sprint Backlog are selected and prioritized
during Sprint Planning. The Product Owner collaborates with the development team
to select the most important and prioritized items from the Product Backlog that can
be completed during the sprint.
• Who Builds It? The Sprint Backlog is built by the development team during Sprint
Planning, with guidance and input from the Product Owner. The team selects the
Product Backlog items they can complete during the sprint and outlines the
necessary tasks to achieve them.
• What Does It Include? The Sprint Backlog consists of:

-9-
www.europeanscrum.org
 o Selected Product Backlog Items: User Stories broken down into tasks and
functionalities prioritized for the sprint.
o Delivery Plan: A detailed plan that includes the tasks necessary to complete
each selected item.
o Sprint Goal: A clear and specific goal that defines what the team aims to
achieve by the end of the sprint.
• Who Updates It? The development team is responsible for updating the Sprint
Backlog daily, reflecting progress and necessary changes, typically during the Daily
Scrum. The Product Owner can provide feedback, but updates are made by the team
to reflect the reality of the work and progress toward the sprint goal.
• Continuous Update: The Sprint Backlog is a dynamic and flexible artifact,
continuously updated by the development team throughout the sprint. During the
Daily Scrum, the team reviews and adjusts the Sprint Backlog as needed to stay
focused on the sprint goal and manage any changes or impediments that arise.

In summary, the Sprint Backlog is a vital tool that guides the development team in their daily
work during the sprint, ensuring that all efforts are aligned with the defined priorities and
product goals.

9 Roles and Responsibilities of a Product Owner

The Product Owner (PO) is a key role in Agile frameworks, especially in Scrum, and is
responsible for maximizing the value of the product resulting from the work of the
development team. The PO acts as the bridge between the stakeholders (customers,
business leaders, users) and the development team, ensuring that the team builds the right
product. Here's a breakdown of the main roles and responsibilities of a Product Owner:

9.1 Roles

1. Strategic Vision
o Vision Definer: The Product Owner is responsible for defining and
communicating the product vision. This role requires a clear understanding of
the organization’s strategic goals and how the product contributes to those
objectives.
o Stakeholder Liaison: Acts as the main point of contact between stakeholders
and the development team, ensuring that the needs and expectations of both
customers and the business are understood and reflected in the product.
2. Product Backlog Management
o Backlog Manager: The Product Owner creates, maintains, and prioritizes the
Product Backlog, ensuring it is always aligned with business priorities and
customer needs.
o Priority Setter: Determines the order in which backlog items should be
addressed, based on factors such as business value, risk, dependencies, and
feedback received.
3. Decision Making
o Decision Maker: Has the authority to make decisions regarding product
functionality and priorities, always aiming to maximize the product’s value.

- 10 -
www.europeanscrum.org
 oPriority Arbitrator: Resolves priority conflicts between stakeholders and
ensures that the team has a clear and prioritized path forward.
4. Communication Facilitator
o Communicator: Facilitates clear and continuous communication between the
development team and stakeholders, ensuring that everyone is aligned
regarding the product’s expectations and progress.
o Feedback Receiver: Gathers continuous feedback from stakeholders and uses
it to adjust and prioritize the Product Backlog.

9.2 Responsibilities

1. Creation and Maintenance of the Product Backlog

o Define Backlog Items: Create clear and detailed descriptions of each backlog
item, including acceptance criteria.
o Refine the Backlog: Collaborate with the development team to refine and
break down backlog items into more manageable and understandable parts.
2. Product Backlog Prioritization
o Evaluate Value: Assess the value of each backlog item in terms of business
benefit, urgency, and strategic alignment.
o Order Items: Prioritize the backlog items to ensure the development team
works on the most important and valuable tasks first.
3. Participation in Scrum Events
o Sprint Planning: Actively participate in sprint planning to select the most
prioritized backlog items and define the sprint goal.
o Sprint Review: Collaborate in reviewing the product increment,
demonstrating its value to stakeholders, and gathering feedback.
o Sprint Retrospective: Optionally participate in the retrospective to offer
insights into collaboration and the development process.
4. Monitoring Progress and Adaptation
o Monitor Progress: Track the team's progress towards product goals and
make necessary adjustments to the Product Backlog.
o Adapt Priorities: Adjust and reprioritize backlog items based on feedback,
market changes, and new opportunities.
5. Ensuring Product Quality
o Definition of Done: Ensure that each increment meets the established
Definition of Done and that the final product meets quality standards and
stakeholder expectations.

In summary, the Product Owner plays a crucial role in managing and directing product
development, ensuring the Scrum team works on the right tasks and that the final product
delivers maximum value to stakeholders and users.

- 11 -
www.europeanscrum.org
10 Artifacts for Defining the Product by the Product Owner
In Agile and Scrum frameworks, the Product Owner uses several artifacts to define, manage,
and communicate the product vision, progress, and requirements. These artifacts help
ensure that the team builds the right product that delivers value to the stakeholders. Here
are the key artifacts for defining the product by the Product Owner:

10.1 Empathy Map

• Definition: The Empathy Map is a tool that helps better understand the end users of
a product. It captures what users think, feel, see, hear, say, and do, as well as their
pains and gains.
o Components: Sections for user thoughts, feelings, observations,
conversations, actions, frustrations, and joys.
o Purpose: To develop a deep and shared understanding of the end user in
order to design solutions that truly meet their needs.
o Relationship with the Scrum Product Owner: The Product Owner uses the
Empathy Map to define and prioritize Product Backlog items that truly solve
problems and add value to users. This tool helps guide decision-making
regarding product features and functionalities.

10.2 Persona Map

• Definition: The Persona Map is a detailed profile of a user archetype representing a

specific market segment. It includes demographic information, behaviors, needs,
goals, and pain points.
o Components: Demographics, psychographics, needs, goals, pain points,
product usage context.
o Purpose: To clearly identify who the product’s users are and what they need,
ensuring that development aligns with user expectations.
o Relationship with the Scrum Product Owner: The Product Owner uses
Persona Maps to ensure that Product Backlog items are aligned with the
needs and characteristics of representative users, helping to prioritize work
based on user value.

10.3 Shadowing

• Definition: Shadowing is a research technique where the observer follows a user in

their natural environment to see how they interact with the product or service.
o Components: Direct observations, notes on user behavior, product
interactions, identification of problems and opportunities.
o Purpose: To gain qualitative insights into real product usage and uncover
unspoken needs and issues.
o Relationship with the Scrum Product Owner: The Product Owner uses
insights gained from Shadowing to identify and prioritize Product Backlog
items that address real user problems and improve the user experience.

- 12 -
www.europeanscrum.org
10.4 Business Canvas

• Definition: The Business Canvas is a visual tool that describes an organization's

business model, including infrastructure, offering, customers, and finances.
o Components: Value proposition, customer segments, channels, customer
relationships, key resources, key activities, key partners, cost structure, and
revenue streams.
o Purpose: To provide a high-level view of the business model and how the
product fits within this context.
o Relationship with the Scrum Product Owner: The Product Owner uses the
Business Canvas to align the product vision with the business strategy,
ensuring that Product Backlog decisions are supported by a viable business
model.

10.5 Product Canvas

• Definition: The Product Canvas is a visual tool that combines aspects of the Business
Canvas with specific details about the product, such as users, their needs, and
product features.
o Components: Personas, customer journeys, product features, success
metrics, value proposition.
o Purpose: To create a comprehensive view of the product, including both
business and user perspectives.
o Relationship with the Scrum Product Owner: The Product Owner uses the
Product Canvas to clearly communicate the product vision, its features, and
how they meet user needs and business goals, informing and prioritizing the
Product Backlog.

10.6 Product Elevator Pitch

• Definition: The Product Elevator Pitch is a brief statement summarizing the unique
value and value proposition of the product in an easy-to-understand form.
o Components: User problem, product solution, key benefits, differentiators.
o Purpose: To communicate the product’s value proposition concisely and
persuasively to stakeholders and the development team.
o Relationship with the Scrum Product Owner: The Product Owner uses the
Product Elevator Pitch to align all stakeholders with the product vision and
ensure that Product Backlog decisions are focused on delivering that unique
value.

10.7 Story Mapping / Scrum Skeleton

• Definition: Story Mapping is a visual technique used to organize and prioritize the
Product Backlog, creating a skeletal structure (Scrum Skeleton) of the product using
user stories.
o Components: User stories organized by functionality and workflow, mapped
on a visual board.

- 13 -
www.europeanscrum.org
 o Purpose: To identify the functional coverage of the product and prioritize
user stories in a way that reflects the incremental value of the product.
o Relationship with the Scrum Product Owner: The Product Owner uses Story
Mapping to visualize pending work, prioritize user stories according to their
value and dependencies, and plan releases and sprints more effectively.

11 General Relationship with the Scrum Product Owner

The Product Owner in Scrum uses these artifacts to better understand users and their
needs, define and prioritize the team's work, and effectively communicate the product's
vision and value. Each tool provides specific insights and helps make informed decisions
about which items should be added to and prioritized in the Product Backlog, ensuring that
product development is aligned with business goals and user expectations.

11.1 Product Vision Definition

The product vision is a clear and concise statement that describes the purpose and long-
term direction of the product. It serves as a guide for the development team and
stakeholders, setting expectations and defining the value that the product should deliver to
its users.

11.2 Expected Characteristics and Qualities

• Clarity: The vision must be easy to understand and communicate.

• Inspiring: It should motivate the team and stakeholders, generating enthusiasm and
commitment.
• User-Centered: It must focus on how the product will benefit end users.
• Achievable: It should be realistic and attainable, providing a clear and concrete goal.
• Value-Oriented: It should highlight the unique value the product will provide to the
market or customers.

11.3 Techniques for Crafting a Vision and Mission

• Brainstorming: Involve key stakeholders and team members in brainstorming

sessions to generate ideas about the product vision.
• SWOT Analysis: Assess the strengths, weaknesses, opportunities, and threats of the
product and the market to define a vision based on a comprehensive analysis.
• Interviews and Surveys: Collect perspectives and expectations from customers,
users, and stakeholders through interviews and surveys.
• Empathy Map: Use this tool to deeply understand users and their needs, which can
help guide the product vision.
• Vision Board: Create a visual board with images, words, and graphics that represent
the product vision to make it more tangible and understandable.

- 14 -
www.europeanscrum.org
11.4 Relationship Between Vision and Product Roadmap

The product roadmap is a strategic plan that outlines how the vision will be realized over
time through the delivery of specific features and improvements. The vision provides the
overall direction and long-term goals, while the roadmap details the steps needed to
achieve them, including key milestones and major deliverables.

11.5 Techniques for Listening to and Understanding the Customer – Socratic

Questioning

Socratic Questioning is a technique for deepening understanding of the customer through

reflective and open-ended questions. Some techniques include:

• Clarifying Questions: "What exactly do you mean by that?"

• Assumption Questions: "What would you assume if this were not true?"
• Evidence Questions: "What evidence do you have to support that statement?"
• Perspective Questions: "How would someone with a different perspective view
this?"
• Consequence Questions: "What would happen if this solution were implemented?"

11.6 Building and Prioritizing the Roadmap / Product Backlog

• Identify Objectives: Based on the product vision, define short-, medium-, and long-
term objectives.
• Break Down into Initiatives: Divide the objectives into smaller, more manageable
initiatives and epics.
• Prioritize the Initiatives: Use techniques like the value/effort matrix, WSJF
(Weighted Shortest Job First), or the MoSCoW method (Must have, Should have,
Could have, Won't have) to prioritize the initiatives.
• Create and Refine the Backlog: Break down prioritized initiatives into detailed user
stories and tasks in the Product Backlog.
• Review and Adjust: Continuously review and adjust the Product Backlog based on
feedback from the team, users, and stakeholders.

12 The Product Owner and Sprint 0

Sprint 0 is an initial planning phase before the first official sprint. It involves preparing a
proposal for the project or product to be developed. It typically includes a preliminary study
on how the product will be implemented. Some common components of Sprint 0 are:

• Scrum Team(s), especially if there are outsourced elements.

• Risk Plan.
• Materials Plan.
• Sprint duration, including if MVPs (Minimum Viable Products) or MMPs (Minimum
Marketable Products) are involved.
• Approximate costs.
• Contract type and billing method.

- 15 -
www.europeanscrum.org
 • A high-level Story Mapping or Product Backlog (Themes, Epics).
• Etc.

The Product Owner plays a crucial role in:

• Defining the Product Vision: Clarifying the initial product vision and objectives.
• Creating the Initial Product Backlog: Establishing a preliminary backlog with well-
defined and prioritized items.
• Setting up the Work Environment: Assisting in configuring the necessary tools,
infrastructure, and processes.
• Setting Expectations: Communicating expectations and aligning with the
development team and stakeholders.

12.1 Dynamic Product Backlog Management

Product Backlog management is a continuous and dynamic process that includes:

• Regular Refinement: Reviewing and updating the backlog regularly, breaking down
large items, and clarifying details.
• Dynamic Prioritization: Adjusting priorities based on new insights, market changes,
and customer feedback.
• Continuous Feedback: Incorporating feedback from sprint reviews, stakeholders,
and users to ensure that the backlog reflects current needs.
• Collaboration: Working closely with the development team and stakeholders to
ensure a shared and aligned understanding of backlog items.
• Transparency: Keeping the Product Backlog accessible and visible to all interested
parties, promoting transparency and alignment.

In summary, the product vision is fundamental in guiding the development and value
delivery in Scrum. The Product Owner uses various techniques and tools to define,
communicate, and realize this vision, ensuring that the development team stays aligned
with the product objectives and user expectations.

13 Types of Contracts in Agile/Scrum

In Agile/Scrum environments, contracts are adapted to reflect the iterative and incremental
nature of software development. Agile contracts need to be flexible enough to
accommodate changes in requirements and the inherent uncertainty of software projects.
Below are some common types of contracts used in Agile/Scrum.

13.1 Client Expectations

• Definition: Client expectations refer to the expected outcomes, features, and

behaviors of the product, as well as associated timelines and costs. In Agile,
managing client expectations is crucial and is achieved through continuous
communication, frequent demonstrations of progress, and incremental delivery of
value.

- 16 -
www.europeanscrum.org
13.2 How It's Handled in Agile/Scrum

• Transparency: Show progress through sprint reviews and demonstrations.

• Continuous Feedback: Obtain and act on client feedback after each sprint.
• Flexible Adjustments: Adapt the backlog and sprint goals based on client feedback.

13.3 Different Contract Types

• Variable Scope: These contracts allow for changes in scope throughout the project
while keeping other aspects like time and cost relatively constant.
• Fixed Scope: Defines a fixed scope from the beginning of the project. This is less
flexible and suitable for projects with very clear and stable requirements.
• Variations: Contracts that allow for variations in scope, time, or cost, typically
through a formal change management process.

Relationship with Agile/Scrum: Variable scope contracts are more compatible with Agile’s
iterative nature, allowing adjustments in response to client feedback and evolving business
needs.

13.4 Time & Material, Fixed Price, Fixed Scope, Cost Ceiling

• Time & Material: The client pays for the time and materials used in the project. It
offers flexibility for changes in scope.
• Fixed Price: The client pays a fixed price for a defined scope of the project. This is
less flexible and can be risky when requirements change.
• Fixed Scope: The project scope is defined from the start and may be associated with
fixed price contracts.
• Cost Ceiling: A maximum cost limit is set for the project. It combines flexibility with
cost control, protecting the client from excessive cost overruns.

Relationship with Agile/Scrum: Time & Material contracts are generally more compatible
with Agile due to their flexibility. Fixed price and fixed scope contracts can be used but
require careful management of changes and risks.

13.5 Phased Development

• Definition: Phased development involves breaking the project into phases or stages,
each with specific goals and deliverables. Each phase acts as an iteration, allowing
for review and adjustment before proceeding to the next.

Relationship with Agile/Scrum: This approach is similar to Agile’s incremental delivery. Each
phase can align with multiple sprints, allowing for continuous adjustments and
improvements based on feedback.

- 17 -
www.europeanscrum.org
13.6 Bonus/Penalty Clauses

• Definition: Contract clauses that offer bonuses for early or high-quality deliveries
and penalties for delays or quality issues.

Relationship with Agile/Scrum: These clauses can motivate the team to meet deadlines and
quality goals. However, they must be handled carefully to avoid incentivizing behaviors that
compromise quality in favor of meeting deadlines.

13.7 Money for Nothing / Changes for Free

• Money for Nothing: This clause allows the client to cancel the project and pay only
for the completed work plus a predefined cancellation fee.
o Relationship with Agile/Scrum: Provides flexibility and reduces the client’s
risk if priorities change significantly.
• Changes for Free: Allows the client to request changes in scope without additional
cost, usually up to a certain agreed point.
o Relationship with Agile/Scrum: Encourages adaptability and quick response
to changing client requirements, aligning well with Agile principles.

13.8 Summary of the Product Owner's Relationship with Contract Types

The Product Owner plays a crucial role in managing client expectations and ensuring the
team's work aligns with the terms of the contract. Their responsibilities include:

• Continuous Communication: Maintain constant communication with stakeholders

and the client to ensure expectations are properly managed.
• Backlog Prioritization: Based on client feedback and contractual clauses, prioritize
Product Backlog items to maximize delivered value.
• Adaptability: Leverage flexible contracts such as Time & Material or variable scope
contracts to allow adjustments in scope without negatively impacting the project.
• Ensuring Quality: Oversee the delivery of high-quality increments, ensuring
alignment with any bonus/penalty clauses.
• Planning and Adjustments: Implement phased development and manage revisions
of the Product Backlog and roadmap to reflect any necessary changes, ensuring the
team remains aligned with the project’s vision and goals.

In summary, the Product Owner must be agile and adaptable, working within the
boundaries of the contract while maximizing the value delivered to the client. They must
also adjust work priorities based on changing requirements and continuous feedback.

- 18 -
www.europeanscrum.org
14 Product/Project Scope (Product Backlog)

14.1 What the Product Backlog Is and Is Not

• What the Product Backlog Is: The Product Backlog is an ordered list of everything
known to be necessary for the product. It serves as the single source of work for the
development team, including new features, improvements, bug fixes, and technical
tasks. It is a living artifact that evolves continuously as new needs are identified and
existing items are refined.
• What the Product Backlog Is Not: The Product Backlog is not a static document or a
list of tasks that never changes. It is not a rigid roadmap or a detailed project plan
that must be followed without flexibility. Nor is it a place to store vague ideas
without intention for prioritization and refinement.

14.2 Prioritization Criteria

Prioritization criteria help the Product Owner order Product Backlog items to maximize the
value delivered to users and the business. The main criteria include:

• Business Value: Positive impact on the business.

• Urgency: Immediate or upcoming need.
• Risk and Uncertainty Reduction: Items that mitigate risks or reduce project
uncertainty.
• Dependencies: Items that unlock or facilitate other work.
• Effort: Estimated cost in time and resources to complete the item.

14.3 Prioritizing the Product Backlog, Releases, and Sprints

• Product Backlog: The Product Owner prioritizes Product Backlog items based on the
mentioned criteria, ensuring that the most valuable and critical business elements
are addressed first. This process is continuous and dynamic, adjusting as new
information and feedback are obtained.
• Releases: The Product Owner plans releases by grouping Product Backlog items into
incremental deliveries that provide tangible value to users. Releases should align
with important business milestones and strategic goals.
• Sprints: During Sprint Planning, the Product Owner collaborates with the
development team to select Product Backlog items to be completed in the upcoming
sprint, prioritizing those that maximize short-term value and are feasible within the
sprint’s time frame.

14.4 Business Critical / Nice to Have, MoSCoW, Kano Model, Pareto Principle

• Business Critical / Nice to Have: The Product Owner categorizes Product Backlog
items as "business critical" or "nice to have," prioritizing those essential for the
product's success.
• MoSCoW Method: A prioritization technique that classifies items into:
o Must have: Essential for the product.

- 19 -
www.europeanscrum.org
 o Should have: Important but not critical.
o Could have: Desirable but not necessary.
o Won’t have: Will not be included in this phase.
• Kano Model: Classifies features into:
o Basic Needs: Minimum expectations.
o Performance Needs: Increase satisfaction proportionally.
o Delighters: Surprise and delight users.
• Pareto Principle: Prioritize the 20% of items that will generate 80% of the value.

14.5 Refining Scope and Continuous Planning

Product Backlog refinement is a continuous activity where the Product Owner and the
development team collaborate to break down and better define backlog items. This ensures
that items are clear, detailed, and ready to be worked on in future sprints. Continuous
planning allows the backlog to be adjusted in response to changes in the business
environment, user feedback, and team outcomes.

14.6 Scope Prioritization (Business Critical & Nice to Have)

Scope prioritization involves the Product Owner ordering Product Backlog items based on
their business criticality and relative value. Business-critical items are prioritized higher,
while "nice to have" items are addressed if time and resources permit, ensuring that value is
maximized with each sprint.

14.7 Project, Releases, and Sprint Completion Criteria – Definition of Done (DoD)

The Definition of Done (DoD) is a shared agreement on the criteria that must be met for a
backlog item, release, or sprint to be considered completed. For the Product Owner, the
DoD ensures the quality and consistency of delivered work.

• DoD for a Product Backlog Item: Includes specific acceptance criteria, complete
testing, updated documentation, and approved code review.
• DoD for a Release: Meets quality requirements, client acceptance, deployment to
production, and release documentation.
• DoD for a Sprint: All sprint items meet their individual DoD, and a sprint review has
been conducted to gather feedback and improve.

14.8 Relationship of the Product Owner with These Concepts

The Product Owner is responsible for managing and prioritizing the Product Backlog,
ensuring that the value delivered to the business and users is maximized. They utilize
prioritization techniques such as MoSCoW, the Kano Model, and the Pareto Principle to
efficiently order the backlog. The Product Owner is also responsible for the continuous
refinement of the backlog and planning, collaborating closely with the development team to
ensure that items are well-defined and ready to be worked on. Scope management includes
implementing a clear Definition of Done (DoD), ensuring that each delivery meets the
agreed-upon quality standards and satisfies the client's expectations.

- 20 -
www.europeanscrum.org
15 Story Mapping and Scrum Board

15.1 Story Mapping

• Definition: Story Mapping is a visual technique that helps teams understand the
product's workflow from the user's perspective. It involves organizing user stories on
a two-dimensional map, where the horizontal axis represents the user’s timeline or
steps, and the vertical axis represents the priority and level of detail of the stories.

Components of Story Mapping:

• Horizontal Axis (User Journey): Describes the user's activities in sequence.

• Vertical Axis (Priority): Classifies stories by their importance and level of detail.
• User Stories: Small functionality pieces described from the user's perspective.
• Releases: Groupings of user stories that form incremental value deliveries.

Benefits of Story Mapping:

• Global Vision: Provides a clear and complete view of the product and its workflow.
• Prioritization: Helps prioritize user stories based on their importance to users and
the business.
• Gap Identification: Facilitates the identification of gaps and areas for improvement
in the user flow.
• Planning: Enables more effective release and sprint planning.

15.2 Scrum Board

• Definition: The Scrum Board is a visual tool used by the Scrum team to manage and
monitor work progress during a sprint. It is a board that shows the sprint tasks and
their current status, typically divided into columns such as "To Do," "In Progress,"
and "Done."

Components of the Scrum Board:

1. Status Columns: "To Do," "In Progress," "Done" (or other customized columns based
on the team’s workflow).
2. Task Cards: Represent tasks derived from the sprint backlog’s user stories.
3. User Stories: May be present as headers or to group related tasks.
4. Team Members: Task owners can be indicated on the cards.

Benefits of the Scrum Board:

• Transparency: Provides a clear view of the work’s status.

• Communication: Facilitates communication and coordination within the team.
• Progress Visualization: Displays sprint progress in real-time.
• Workflow Management: Helps manage and balance the team's workload.

- 21 -
www.europeanscrum.org
15.3 Relationship Between Story Mapping and Scrum Board from the Product
Owner's Perspective

Complementarity:

• Global Vision vs. Detailed Execution: Story Mapping provides a strategic, global view
of the product, helping the Product Owner understand the value flow from the
user's perspective. In contrast, the Scrum Board focuses on the tactical execution of
work during sprints, displaying the daily progress and status of specific tasks.

Planning and Prioritization:

• Use in Planning: The Product Owner uses Story Mapping to identify and prioritize
user stories and plan releases. This map helps break down stories into manageable
tasks, which are then transferred to the Scrum Board for execution during sprints.
• Tracking Progress: While Story Mapping is useful for initial planning and backlog
prioritization, the Scrum Board allows the Product Owner and the development
team to track daily progress, ensuring that priority tasks are completed on time.

Collaboration and Communication:

• Product Communication: Story Mapping facilitates communication of the product

vision and workflow to the development team and stakeholders. The Scrum Board,
on the other hand, facilitates daily communication and coordination within the team
during sprints.

Iteration and Refinement:

• Continuous Refinement: The Product Owner can use Story Mapping to review and
adjust the Product Backlog based on feedback received after each sprint. Refined
stories are then moved to the Scrum Board for implementation in future sprints.

Conclusion: Story Mapping and the Scrum Board are complementary tools that help the
Product Owner manage and communicate both the product’s global vision and the detailed
progress of daily work. While Story Mapping supports strategic planning and the
prioritization of user stories, the Scrum Board is essential for tactical management and
progress tracking during sprints. Together, these tools ensure that the development team
remains aligned with the product’s goals and that incremental value is delivered efficiently.

- 22 -
www.europeanscrum.org
16 Decomposition in Scrum

16.1 Themes, Epics, User Stories, and Tasks

• Themes: Themes are high-level groupings of work that represent large areas of
functionality or product features. A theme can span multiple epics and, therefore,
many user stories. Themes help the Product Owner organize and prioritize work on a
large scale, ensuring alignment with the product’s strategic goals.
• Epics: Epics are large bodies of work that can be broken down into multiple user
stories. They represent complete and complex functionalities that cannot be
completed in a single sprint. Epics allow the Product Owner to manage and prioritize
large functionalities in a more manageable way, ensuring they are broken down into
smaller, manageable user stories when necessary.
• User Stories: User stories are brief descriptions of functionality from the perspective
of the end user. Each user story should provide tangible value and be small and clear
enough to be completed within a sprint. They are the basic unit of work in Scrum,
and the Product Owner is responsible for writing, prioritizing, and refining these
stories.
• Tasks: Tasks are detailed breakdowns of user stories. They represent the specific
steps the development team must take to complete a user story. The Product Owner
collaborates with the team to ensure tasks are clear and well-defined.

16.2 What is a User Story?

A user story is a simple description of a functionality written from the end user’s
perspective. Its goal is to capture what the user wants and why. A good user story should be
Independent, Negotiable, Valuable, Estimable, Small, and Testable (INVEST).

16.3 Grammar of User Stories

User stories typically follow the format: “As a [type of user], I want [a functionality] so that [I
can achieve a benefit].”
Example: "As a registered user, I want to reset my password so that I can regain access to
my account."

17 Definition of Sprints

17.1 Who Defines Sprints?

The Scrum team as a whole defines the structure of sprints. The Product Owner is
responsible for defining the sprint goals and prioritizing Product Backlog items, while the
development team decides how much work they can commit to completing within the
sprint.

- 23 -
www.europeanscrum.org
17.2 Fixed or Variable Length?

Sprints have a fixed length, typically between 1 to 4 weeks. This fixed cadence provides a
constant and predictable rhythm for the team, allowing for regular planning and review of
progress.

17.3 Relationship Between Sprints, Releases, MVP, and MMP

• Sprints: Fixed-length work cycles in which the team delivers product increments.
• Release: A grouping of multiple sprints that results in a deliverable version of the
product.
• MVP (Minimum Viable Product): The minimum version of the product with enough
functionality to satisfy early users and provide feedback for future development.
• MMP (Minimum Marketable Product): The minimum version of the product that is
good enough to be launched to the market and attract a larger user base.

Sprints contribute to building releases, MVPs, and MMPs through the continuous delivery of
value increments.

17.4 Sprint Goal

The goal of a sprint is to create a product increment that is potentially deliverable and adds
value to the user and the business. This goal is agreed upon at the start of the sprint during
Sprint Planning.

17.5 Definition of Done (DoD)

The Definition of Done (DoD) is a checklist of criteria that must be met for a Product
Backlog item or increment to be considered complete. It includes aspects such as testing,
documentation, and code review. The Product Owner ensures that the DoD is clearly
defined and consistently followed.

17.6 Validation and Sprint Review

• Validation: During the sprint, the Product Owner validates the work being done,
ensuring it meets the acceptance criteria and the Definition of Done. This continuous
validation helps avoid surprises at the end of the sprint.
• Sprint Review: At the end of each sprint, the Sprint Review is conducted, where the
team presents the product increment to stakeholders. The Product Owner leads this
meeting, showcasing new features and gathering feedback. This event is crucial for
adjusting the Product Backlog and ensuring development remains aligned with
business needs and expectations.

- 24 -
www.europeanscrum.org
17.7 Relationship Between Decomposition and Sprints from the Product Owner’s
Perspective

The Product Owner uses decomposition (Themes, Epics, User Stories, and Tasks) to
effectively organize and prioritize the Product Backlog. This approach breaks down large
functionalities into smaller, manageable pieces that can be completed within a sprint. When
planning sprints, the Product Owner selects prioritized user stories, collaborating with the
development team to decompose them into specific tasks.

Additionally, the Product Owner ensures that each sprint has a clear goal aligned with the
product vision, and that the resulting increments are validated and reviewed properly. The
Sprint Review is used to adjust and refine the Product Backlog based on the feedback
received. This continuous cycle of planning, execution, and review ensures that the product
evolves coherently and efficiently, always aligned with the needs of both users and the
business.

18 Change Management 3.0 in Scrum

Change Management 3.0 in Scrum focuses on continuous adaptation and flexibility within
the agile development environment, promoting effective collaboration and communication
among all stakeholders. Key aspects from the Product Owner’s perspective include:

18.1 Change Management with Clients, Scrum Teams, and Contracts

• With Clients: The Product Owner maintains open and continuous communication
with the client, ensuring that any changes in requirements or priorities are managed
effectively. This includes:
o Regular Feedback: Collecting and analyzing client feedback during and after
each sprint and release.
o Transparency: Keeping the client informed about progress, change decisions,
and their impacts.
o Expectation Alignment: Ensuring client expectations align with the team's
capabilities and project realities.
• With the Scrum Team: The Product Owner acts as a bridge between the
development team and external stakeholders, facilitating understanding and
acceptance of changes. This includes:
o Priority and Clarity: Clearly communicating priorities and the impact of
changes on the Product Backlog.
o Collaboration: Engaging the team in discussions about changes to leverage
their technical and operational expertise.
o Adaptation: Helping the team adapt to new requirements or changes in
priorities.
• With Contracts: Agile contracts should be flexible and adaptable, allowing changes
throughout the project. The Product Owner should:
o Include Flexibility: Ensure contracts allow for scope and priority adjustments
without excessive penalties.
o Define Clear Terms: Establish clear terms on how changes will be managed
and how they will affect timelines and costs.

- 25 -
www.europeanscrum.org
18.2 Grooming/Refinement

Backlog refinement, also known as grooming, is the continuous process of reviewing and
adjusting Product Backlog items to ensure they are ready for future sprints. From the
Product Owner’s perspective, this involves:

• Prioritization: Continuously adjusting the backlog priorities based on customer

feedback, market changes, and business needs.
• Clarity and Detail: Ensuring user stories are clear, detailed, and well-defined for
efficient work by the development team.
• Collaboration: Working closely with the development team to refine and break
down large user stories into manageable tasks.

18.3 Contingency Reserve

A contingency reserve is a buffer of time or resources added to handle unforeseen events or

changes. From the Product Owner’s perspective, managing it includes:

• Planning: Including time buffers in sprint and release planning to accommodate

unexpected changes.
• Active Management: Regularly reviewing and adjusting the contingency reserve
based on past sprint experiences and team feedback.
• Communication: Keeping stakeholders informed about the existence and use of the
contingency reserve to manage expectations.
• Typical Range: It can vary, but usually, 10-20% of the Development Team or Sprint
capacity is reserved for contingencies.

18.4 Decision-Making Analysis

The Product Owner must constantly analyze feedback and available data to make informed
product decisions. This involves:

• Data Analysis: Using performance metrics, customer feedback, and market analysis
to make informed decisions.
• Value-Based Decisions: Prioritizing changes and developments based on the value
they bring to the customer and the business.
• Collaboration: Involving the team and stakeholders in the decision-making process
to ensure all perspectives are considered.

18.5 Evolutionary and Iterative Development – Releases/Sprints

Evolutionary and iterative development is at the core of the agile approach, where the
product is developed in small, frequent increments. From the Product Owner’s perspective,
this involves:

- 26 -
www.europeanscrum.org
 • Release Planning: Defining releases that provide significant and tangible value to the
customer, breaking down the work into manageable sprints.
• Continuous Iteration: Continuously adapting and refining the product based on
feedback received at the end of each sprint.
• Clear Objectives: Setting clear goals for each sprint that align with the product vision
and strategy.
• Regular Validation: Validating completed work at the end of each sprint through the
Sprint Review, ensuring it meets the Definition of Done and delivers value.

18.6 Relationship with the Product Owner

The Product Owner plays a central role in Change Management 3.0, ensuring that the
Scrum team remains aligned with client and business objectives while adapting effectively
to changes. This includes:

• Continuous Communication: Maintaining a constant flow of communication with

the client and the team to manage changes and adjustments.
• Dynamic Prioritization: Continuously adapting and prioritizing the Product Backlog
based on feedback and evolving needs.
• Risk Management: Using contingency reserves and data analysis to mitigate risks
and handle unforeseen events.
• Incremental Delivery: Planning and executing releases and sprints that deliver
incremental value to the client, adjusting as necessary to continuously improve the
product.

In summary, the Product Owner is a key facilitator in Change Management 3.0, ensuring
that the Scrum team can adapt and respond quickly to changes while maintaining a constant
focus on delivering value.

19 Relationship Between Scrum and Design Thinking

19.1 User-Centric Focus

1. Design Thinking: Begins with a deep understanding of the user's needs through
empathy and research.
2. Scrum: Continues delivering value to the user through frequent iterations and the
continuous incorporation of feedback.

19.2 Iteration and Incremental Development

1. Design Thinking: Iterates through prototypes and tests to refine solutions.

2. Scrum: Uses iterative sprints to develop product increments and adjust based on
feedback received at the end of each sprint.

- 27 -
www.europeanscrum.org
19.3 Collaboration and Cross-Functional Teams

1. Design Thinking: Encourages collaboration among diverse roles and perspectives

during the ideation and prototyping phases.
2. Scrum: Promotes cross-functional teams working together in each sprint to deliver
product increments.

19.4 Problem-Solving Approach

1. Design Thinking: Clearly defines problems before seeking creative solutions.

2. Scrum: Solves problems through iterative development and continuous value
delivery.

19.5 Implementation from the Product Owner’s Perspective

Integrating Design Thinking into the Scrum Process

• Empathy and Definition Phase (Design Thinking) in Sprint 0 (Scrum):

o Before starting regular sprints, the Product Owner can lead Design Thinking
sessions to understand user needs and define the problems the product
should solve.
o Activities such as creating Empathy Maps, Personas, and defining key
problems help build a solid foundation for the Product Backlog.
• Ideation and Prototyping (Design Thinking) during Backlog Refinement (Scrum):
o During backlog refinement sessions, the Product Owner can use Design
Thinking techniques to ideate and prioritize solutions.
o Rapid prototyping and early feedback can inform and improve user stories in
the Product Backlog.
• Iterative Development (Scrum) with Continuous Feedback (Design Thinking):
o Each Scrum sprint can include feedback loops and user testing, which are
essential in Design Thinking.
o The Product Owner should ensure that user feedback is collected and
analyzed at the end of each sprint during the Sprint Review, using this
information to refine the Product Backlog and adjust the product’s direction.
• Solution Validation (Design Thinking) in the Sprint Review (Scrum):
o The Sprint Review offers an excellent opportunity to validate solutions with
stakeholders and users.
o The Product Owner can present the developed increments, gather feedback,
and adjust priorities and solutions based on that feedback.

19.6 Benefits of Integration

• Greater User Focus:

o Combining Design Thinking and Scrum ensures that the team not only
delivers value quickly but also aligns that value with real user needs.
• Innovation and Creativity:

- 28 -
www.europeanscrum.org
 o Integrating Design Thinking's ideation and prototyping phases into the Scrum
process allows the team to generate more creative and innovative solutions.
• Continuous Improvement:
o Continuous feedback and iteration enable constant product improvement,
aligning with Scrum’s philosophy of incremental and continuous value
delivery.
• Risk Reduction:
o By validating hypotheses and solutions through early prototypes and tests,
risks can be identified and mitigated before committing significant resources
to development.

19.7 Conclusion

From the Product Owner's perspective, integrating Design Thinking into Scrum allows for
greater alignment with user needs, fosters creativity and innovation, and ensures
continuous value delivery. By combining these approaches, the Product Owner can lead the
development of products that are not only functional and of high quality but also deeply
connected to users' expectations and desires.

20 Relationship Between Scrum, Kanban, and Lean from the Product

Owner's Perspective
Scrum, Kanban, and Lean are agile methodologies that complement each other to improve
efficiency and value delivery in product development projects. Each approach has its own
principles and practices, but they all share the goal of optimizing workflow and maximizing
customer value.

20.1 Scrum from the Product Owner's Perspective

Scrum is an agile framework focused on the incremental and iterative delivery of products
through short, regular sprints. The Product Owner in Scrum is responsible for maximizing
product value by managing the Product Backlog and ensuring the development team works
on the right priorities.

20.2 Kanban

Kanban is a visual method for managing work in progress (WIP) and improving workflow
efficiency. It uses a Kanban board to visualize task progress and limits WIP to identify and
eliminate bottlenecks.

20.3 Lean

Lean is a management philosophy focused on eliminating waste, continuous improvement,

and maximizing customer value. It is based on principles such as just-in-time value delivery
and optimizing workflow.

- 29 -
www.europeanscrum.org
20.4 Relationship Between Scrum and Kanban

• Work Visualization:
1. Kanban: Uses Kanban boards to visualize the status of all tasks and limit WIP.
2. Scrum: Uses Scrum boards to manage and visualize tasks within the current
sprint.
3. Product Owner: Can combine both approaches by using Kanban to visualize
the full backlog and Scrum for sprint tasks.
• WIP Management:
1. Kanban: Limits WIP to identify bottlenecks and improve workflow.
2. Scrum: Each sprint has a fixed work capacity, acting as a natural WIP
limitation.
3. Product Owner: Can apply Kanban principles within sprints to manage WIP
and ensure the team is not overloaded.
• Continuous Delivery:
1. Kanban: Allows continuous delivery of value as tasks are completed.
2. Scrum: Delivers product increments at the end of each sprint.
3. Product Owner: Can combine Kanban’s continuous delivery with Scrum’s
iterative cycles to maximize flexibility and responsiveness.

20.5 Relationship Between Scrum and Lean

• Waste Elimination:
1. Lean: Focuses on eliminating all forms of waste, including unnecessary tasks,
delays, and defects.
2. Scrum: Sprint retrospectives help identify and eliminate waste in the
development process.
3. Product Owner: Must work with the team to identify and eliminate any
activities that do not add value to the product or customer.
• Continuous Improvement (Kaizen):
1. Lean: Promotes continuous improvement through small, incremental
changes.
2. Scrum: Uses retrospectives for continuous process improvement.
3. Product Owner: Should foster a culture of continuous improvement,
constantly seeking ways to optimize the backlog and the delivery process.
• Just-in-Time Value:
1. Lean: Delivers value just-in-time, avoiding unnecessary inventory and
reducing waiting times.
2. Scrum: Delivers value at the end of each sprint, ensuring that the work done
aligns with the current customer priorities.
3. Product Owner: Must prioritize the backlog to ensure that high-value tasks
are worked on first and delivered as soon as they are ready.

20.6 Conclusion

From the Product Owner's perspective, integrating Scrum, Kanban, and Lean methodologies
can significantly enhance the value delivery process. Scrum’s structured sprints can be

- 30 -
www.europeanscrum.org
complemented by Kanban’s visual management and WIP control, while Lean’s focus on
waste elimination and continuous improvement aligns with the agile philosophy. By
combining these approaches, the Product Owner ensures that the team remains focused on
delivering high-value increments while continuously improving processes and optimizing
workflow.

21 Implementation from the Product Owner's Perspective

21.1 Integration of Kanban into the Scrum Process

• Backlog Visualization:
1. The Product Owner can use a Kanban board to visualize the entire Product
Backlog, making it easier to prioritize and manage the workflow.
• WIP Management:
1. Limiting WIP (Work In Progress) on the Kanban board helps maintain focus
and prevents team overload. This is particularly useful during backlog
refinement and sprint planning.

21.2 Integration of Lean into the Scrum Process

• Waste Elimination:
1. The Product Owner should identify and eliminate tasks and processes that do
not add value by using sprint retrospectives and continuous feedback.
• Continuous Improvement:
1. Fostering a culture of continuous improvement within the team by using
Scrum retrospectives to implement incremental changes and improve the
process.
• Just-In-Time Value:
1. Ensuring that user stories and tasks are prioritized and planned in a way that
delivers value just in time, avoiding unnecessary backlog accumulation.

21.3 Benefits of Integration

• Increased Transparency:
1. Combining Kanban boards with Scrum provides a clear and complete
visualization of the work’s status and priorities.
• Workflow Optimization:
1. Limiting WIP and eliminating waste improves team efficiency and speeds up
value delivery.
• Flexibility and Adaptability:
1. Integrating Kanban and Lean increases adaptability to changes, enhancing the
team’s ability to respond to new priorities and customer needs.
• Continuous Improvement:
1. Encouraging a culture of continuous improvement ensures that the team
always seeks ways to optimize their work and deliver more value to the
customer.

- 31 -
www.europeanscrum.org
21.4 Conclusion

From the Product Owner’s perspective, integrating Scrum with Kanban and Lean can
significantly improve the development team’s efficiency and responsiveness. By combining
these approaches, the Product Owner can maximize customer value delivery, optimize
workflow, and foster a culture of continuous improvement. This ensures that the product is
not only delivered efficiently but also aligned with the evolving needs and expectations of
the customer and the market.

22 Best Practices of a Good Product Owner

• Understanding the Customer and the Market: A good Product Owner (PO) must
have deep knowledge of customer needs and market trends, using tools like
interviews, surveys, and data analysis.
• Effective Product Backlog Management: Maintaining an organized and prioritized
Product Backlog is crucial. The PO should review and update the backlog regularly to
ensure it reflects current priorities.
• Continuous Collaboration: Collaborate closely with the Scrum Team, stakeholders,
and end users to ensure clear communication and alignment with product goals.
• Clarity in User Stories: Write clear and detailed user stories with well-defined
acceptance criteria to guide the development team and ensure they fully understand
the requirements.
• Value-Based Prioritization: Prioritize work based on the value it provides to the
customer and the business, using techniques like MoSCoW, the Kano Model, and
cost-benefit analysis.
• Continuous Feedback: Continuously collect and analyze feedback from both the
team and users, using it to adjust and improve the product and development
process.
• Product Vision and Strategy: Define and communicate a clear product vision and
strategy to guide the team and keep all stakeholders aligned.
• Stakeholder Management: Manage stakeholder expectations and needs, ensuring
their involvement and alignment with the product vision.
• Flexibility and Adaptability: Be flexible and adaptable to changes in business or
market priorities, adjusting the backlog and development strategies as needed.
• Participation in Scrum Events: Actively participate in Scrum events, such as Sprint
Planning, Review, and Retrospective, to guide the team and ensure continuous
alignment with product goals.
• Focus on Quality: Prioritize product quality, ensuring proper testing is conducted
and that the team maintains high standards of quality.
• Education and Training: Continuously improve their skills and knowledge about the
product, market, and agile practices, sharing that knowledge with the team.

Implementing these best practices will help the Product Owner maximize the value
delivered to the customer, ensure product quality, and improve the development team’s
efficiency.

- 32 -
www.europeanscrum.org
23 Acknowledgments.
We would like to express our deepest gratitude to everyone who contributed to the
creation of this guide. Special thanks to Yvonne Agnes, Silke Schöll, Ramón Berenguer, and
David Martí for their tireless efforts and dedication in providing a valuable resource for the
Scrum community. We are also grateful to all the professionals who shared their
experiences, feedback, and improvements throughout the development of this work.

Finally, we would like to thank all the Product Owners, Scrum Masters, and development
teams who apply and refine agile practices every day, contributing to the growth of a
culture of continuous improvement and value delivery. Thank you for being part of this
community and for making the world of product development more agile, efficient, and
customer-focused!

Any suggestions or feedback on this guide are most welcome. Feel free to reach out to us at
[email protected]. Together, we will continue to improve!

- 33 -
www.europeanscrum.org