How to Prepare for Certification Test

Professional Scrum Product Owner™ I

The accountabilities of the Product Owner go well beyond managing the Product
Backlog. The PO is pivotal to bridging business strategy and product execution in order
to help the organization create valuable products.

Outcomes_________________________________________________________________________ 2
Objectives_________________________________________________________________________ 2
Certification Details__________________________________________________________________ 2
The Professional Scrum™ Competencies_____________________________________________________ 3
The Scrum Guide_________________________________________________________________ 3
Understanding and Applying the Scrum Framework_________________________________________ 3
Developing People and Teams________________________________________________________ 3
Managing Products with Agility_______________________________________________________ 3
Developing and Delivering Products Professionally__________________________________________ 3
Evolving the Agile Organization_______________________________________________________ 3
Product Owner Learning Path____________________________________________________________4
Resources for Product Owners___________________________________________________________ 4
Developing Product Ownership Competency______________________________________________ 4
Engage with Vision________________________________________________________________ 4
Lead to Value___________________________________________________________________ 4
Evolve with Validation______________________________________________________________4
Learn Professional Product Ownership__________________________________________________ 4
Les clés d’une stratégie simple & efficace________________________________________________ 4
Open Assessments___________________________________________________________________ 5
Scrum Open_____________________________________________________________________5
Product Owner Open_______________________________________________________________5
Autres Ressources____________________________________________________________________ 5
Entraînements______________________________________________________________________ 6
Scrum Open & Product Owner Open____________________________________________________ 6
Scrum______________________________________________________________________7
The Scrum Team______________________________________________________________ 8
The Product Backlog___________________________________________________________ 8
The Increment________________________________________________________________ 9
The Definition of Ready & the Definition of Done_______________________________________ 10
The Sprint Planning____________________________________________________________10
The Sprint Goal______________________________________________________________ 11
The Sprint Backlog____________________________________________________________ 11
The Sprint__________________________________________________________________ 11
The Daily Scrum______________________________________________________________ 13
Product Backlog Refinement_____________________________________________________ 13
The Sprint Review_____________________________________________________________ 13
The Sprint Retrospective________________________________________________________ 14
The Product Owner____________________________________________________________ 14
The Scrum Master_____________________________________________________________15
Events and timeboxes__________________________________________________________ 16
Outcomes

●​ Improving value created by staying focused on value and outcomes

●​ Increasing organizational learning validating sooner rather than later which will
also reduce costs
●​ Achieving better business outcomes by aligning initiatives with business strategy
through shared vision and aligning people toward clear goals
●​ Increasing business agility by being data informed and empirical

Objectives

●​ Understand that Product Ownership includes Product Management performed

with an Agile mindset
●​ Recognize the value of a product over project mindset
●​ Learn how to bridge business strategy to product development tactics
●​ Experience ways to align the team around the business strategy, product vision,
Product Goal and Sprint Goal
●​ Find ways to effectively communicate the business strategy, product vision and
Product Goal
●​ Discover techniques to collaborate with users, customers, stakeholders and
members of the Scrum Team
●​ Identify metrics that can be used to track value creation and successful product
delivery
●​ Learn how quality and the Definition of Done support long term product viability
and reduce time to market
●​ Understand the Scrum Principles and Empiricism
●​ Understand the Product Owner accountability on the Scrum Team
●​ Learn techniques for Product Backlog Management, Release Management and
Forecasting

Certification Details

Time limit: 60 minutes

Number of Questions: 80

Passing score: 85% (68 correct answers)

Format: Multiple Choice, Multiple Answer, True/False

Language: English
The Professional Scrum™ Competencies

https://www.scrum.org/professional-scrum-competencies

The Scrum Guide

https://www.scrum.org/scrum-guide-2020

https://scrumguides.org/index.html

Understanding and Applying the Scrum Framework

https://www.scrum.org/professional-scrum-competencies/understanding-and-applying-
scrum-framework

Empiricism, Scrum Values, Scrum Team, Events, Artifacts, Done, Scaling

Developing People and Teams

https://www.scrum.org/resources/professional-scrum-competency-developing-people-a
nd-teams

Facilitation, Teaching, (Self-Managing Teams)

Managing Products with Agility

https://www.scrum.org/professional-scrum-competencies/managing-products-with-agil
ity

Forecasting & Release Planning, Product Vision, Product Value, Product Backlog
Management, Business Strategy, Stakeholders & Customers

Developing and Delivering Products Professionally

Emergent Software Development, Managing Technical Risk

Evolving the Agile Organization

Evidence Based Management

Product Owner Learning Path

https://www.scrum.org/pathway/product-owner-learning-path/

Resources for Product Owners

Maximizing Value for Your Customers, Users, and Organization as a Product Owner

https://www.scrum.org/resources-product-owners

Developing Product Ownership Competency

Engage with Vision

Lead to Value

Evolve with Validation

Learn Professional Product Ownership

Les clés d’une stratégie simple & efficace

par Tiphanie Vinet - Coach produit chez BENEXT

Une bonne stratégie doit être :

●​ Audible (facile à exprimer)

●​ Accessible (chacun peut la consulter et chaque mot est clair)
●​ Actionnable (mesurable)

Par la suite, les conseils donnés durant la keynote sont plutôt classiques :

●​ Définir le périmètre en jeu

●​ Récolter le maximum d’informations et les inputs
●​ Lister les décisions attendues
●​ Remplir un canevas indiquant la vision et l’axe de travail
●​ Utiliser les KPI (indicateurs-clé de performance)
●​ Utiliser les OKR (Objectives and Key Results)
●​ Communiquer et mesurer régulièrement
Open Assessments

Scrum Open

https://www.scrum.org/open-assessments/scrum-open

Product Owner Open

https://www.scrum.org/open-assessments/product-owner-open

Other Resources

-​ Scrum Glossary

-​ [PDF] Product Strategy Canva

-​ [Slides] The Empirical Product Owner - Mark Noneman

-​ [Videos] Scrum Guide 2020 - Formation Scrum PO - La Minute Agile

-​ The Professional Product Owner: Leveraging Scrum as a Competitive Advantage

- Don McGreal, Ralph Jocham

-​ A burn-down chart shows how much work remains till the end of a Sprint.

-​ The Cone of Uncertainty is a concept that describes the level of uncertainty and
risk associated with a project at different stages of the development process. It
suggests that as a project progresses, this level decreases.

-​ MoSCoW is a technique for prioritizing requirements based on their importance :

Must have, Should have, Could have, Won’t have.

-​ Scaling Scrum with Nexus

-​ Empiricism, the act of making decisions based on what is - Ken Schwaber. A

“commitment” in Scrum is a pledge to do our best with what we have.
Trainings

Scrum Open & Product Owner Open

- An organization has decided to adopt Scrum, but management wants to change

the terminology to fit with terminology already used. What will likely happen if
this is done?
- What is the function or purpose of Management in Scrum?
- What is the typical size for a Scrum Team?
- When should a Developer on a Scrum Team be replaced?
- How much work must the Developers complete for each Sprint?
- When does a Developer become accountable for the value of a Product Backlog
item selected for the Sprint?
- Who is responsible for managing the progress of work during a Sprint?
- During a Sprint, a Developer determines that the Scrum Team will not be able to
complete the items in their forecast. Who should be present to review and adjust
the Product Backlog items selected?
- The CEO asks the Developers to add a "very important" item to a Sprint that is
in progress. What should the Developers do?
- When might a Sprint be cancelled?
- Who should know the most about the progress toward a business objective or a
release, and be able to explain the alternatives most clearly?
Scrum

Scrum is a framework for complex product development or maintenance, regardless of

whether the work is organized in projects. Its essence is a small team of people that is highly
flexible and adaptive. It can be used for the development of almost everything we use in our
daily lives as individuals and societies : products and enhancements, software and hardware,
sustaining of Cloud and other operational environments. It can also be used for managing
the operation of an organization, for research and identifying viable markets, technologies
and product capabilities. 90% of Agile Teams use Scrum, and 12 million people are using
Scrum daily.

It is founded on empiricism and lean thinking. The three pillars uphold empirical and lean
thinking : transparency, inspection, and adaptation. The five values of Scrum are :
commitment, respect, focus, openness, courage.

The Scrum framework consists of Scrum Teams and their associated events, artifacts, rules
and accountabilities (there are no roles). It is meant to be implemented as prescribed in the
Scrum Guide : its elements are mandatory and have a specific purpose.

Scrum does not eliminate the complexity that is inherent in delivering a product in today’s
world, instead it offers a framework for optimizing decision making based on the knowledge
and experience of the entire team. By regularly delivering Increments of value and making
significant aspects of the process visible to those responsible of the outcome, teams gain the
ability to inspect and rapidly adapt based on the feedback received.

-​ An organization has decided to adopt Scrum, but management wants to change

the terminology to fit with terminology already used. What will likely happen if
this is done?
Without a new vocabulary, very little change may actually happen. The organization may not
understand what has changed with Scrum and the benefits of Scrum may be lost.

-​ What is the function or purpose of Management in Scrum?

Management has no official accountability on a Scrum Team. However, project managers are
not simply replaced by self-managing teams. A traditional project manager is still
responsible for all aspects of a project : costs, resources, execution, release, planning,
capacity. And management external to the Scrum Team is relevant in :

-​ setting the vision and strategy to guide the overall direction of the organization
-​ supporting the Product Owner with insights and information into high value product
and system capabilities
-​ supporting the Scrum Master to encourage organizational change that fosters
empiricism, self-management, bottom-up intelligence, and intelligent product
delivery
The Scrum Team

It is a cohesive unit of professionals focused on one objective at a time : the Product Goal, in
the Product Backlog. The Scrum Team consists of one Scrum Master, one Product Owner and
Developers. It is allowed, but not recommended, that a person has more than one Scrum
accountability at the same time.

Scrum Team members do not have technical titles, and no sub-teams; such as testing,
architecture, or operations are recognized. All kinds of testing should be done during the
Sprint : test-driven development, unit tests, acceptance tests. Accountability belongs with the
Scrum Team as a whole, regardless of whether team members have specialized skills.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to
create a product Increment and create value each Sprint. They are also self-managing,
meaning they internally decide who does what, when, and how, which increases
predictability, individual buy-in and creativity. The Developers are a group of professionals
who do the work of delivering an Increment of done product at the end of each Sprint.

-​ What is the typical size for a Scrum Team?

A Scrum Team is small enough to remain nimble and large enough to complete significant
work within a Sprint, typically 10 or fewer people (3 to 9).

-​ When should a Developer on a Scrum Team be replaced?

As needed, while taking into account a short-term reduction in productivity. Scrum Teams
typically go through some steps before achieving a state of increased performance.
Changing membership typically reduces cohesion, affecting performance and productivity in
the short term.

The Product Backlog

The Product Backlog is the project plan in Scrum. It is an emergent list of what is needed to
improve the product, available to all stakeholders.

Who are stakeholders? Anyone affected by or having an interest in the product or project.
This includes users, customers (purchasers), internal sponsors, management, support teams,
marketing, sales, legal, finance, developers, etc. The end-user or customer is considered
paramount, especially in product development.

The Product Backlog is the single source of work undertaken by the Scrum Team and it
evolves as the product and the environment in which it will be used evolves.

Anyone can contribute items to the Product Backlog, at any time. The Product Owner then
prioritizes and refines these items. Even if the responsibility is delegated, the Product Owner
remains accountable for the content, availability and ordering of the Product Backlog.

Product Backlog items have the attributes of description, order and size (estimate). The
Developers are responsible for all estimates. Indications of value may be useful but are only
a prediction until validated by users and the market. The PBI can be represented by any
technique, even a mix of several techniques : user stories, scenarios, acceptance tests, use
cases… Most valuable and clear items are at the top of the Product Backlog. Other valid
considerations when ordering are :

-​ Dependencies on other Product Backlog items, as they may introduce risks,

constraints, or uncertainties that affect the value delivery
-​ Dependencies to other products
-​ Importance to customers
-​ Alignment with business strategy and goals
-​ Cost of implementation and delay
-​ Risk

Products have one Product Goal, one Product Backlog and one Product Owner, regardless of
how many Scrum Teams are used. Any other setup makes it difficult for the Developers to
determine what they should work on.

The Increment

An Increment is a concrete stepping stone toward the product vision. It is the sum of all the
Product Backlog items completed during a Sprint and the value of the increments of all
previous Sprints. At the end of a Sprint, the new Increment must be “Done”, which means it
meets the Definition of Done and is usable, but it does not have to be released.

The main value of releasing the Increment regularly to customers or users is to validate
assumptions about the product value made when creating the product. It can also provide
these benefits :

-​ obtaining feedback and data from real users and customers

-​ increasing customer satisfaction and loyalty
-​ reducing risks and uncertainties

The Definition of Ready & the Definition of Done

Although not a Scrum element, the Definition of Ready ensures that items are well-defined
and ready for development, integrating the maximum percentage of complete acceptance
criteria.

The Definition of Done is a formal description of the state of the Increment when it meets
the quality measures required for the product. It is a shared understanding among the
Scrum Team and the stakeholders of what has been done at the end of each Sprint.

The Developers are accountable for the Definition of Done, because they are accountable for
creating a “Done” Increment in every Sprint. If the Definition of Done is not a part of the
standards of the organization, the Developers must create one appropriate for the product.
This definition helps to forecast the team’s productivity over time and affects the product’s
total cost of ownership, reducing technical debt. It should not be changed during the Sprint
and only the Developers are allowed to adjust it.
When many Scrum Teams are working on a single product, there are several Sprint Backlogs,
but only one Product Backlog and one Product Owner. The teams should share a single
Definition of Ready & Definition of Done for the Increment. They are not required to have the
same Sprint length, but it is their responsibility to work together to create an integrated
Increment that is inclusive of all teams’ work.

The Sprint Planning

During Sprint Planning, the Scrum Team crafts the Sprint Goal, and the Sprint Backlog which
is a set of Product Backlog items selected as most valuable. The event answers the following
questions :

-​ Why is the team building the Increment ?

-​ What can be delivered in the Increment resulting from the upcoming Sprint ?
-​ How will the work needed to deliver the Increment be achieved ?

The Product Owner should come to Sprint Planning with a business objective in mind, the
Definition of Done, ensuring that attendees discuss the most important Product Backlog
items and how they map to the Product Goal.

During the event, the Developers identify and estimate the necessary work to meet the
Sprint Goal, and enough of the Sprint Backlog must be defined so the Developers can create
their forecast of what work they can do.

The Developers can select a Product Backlog item based on their understanding of its value,
scope, and complexity, as well as their capacity and skills. An item is ready for development
when it is estimated, refined and small enough to fit in one Sprint. Developers can
collaborate with the Product Owner to define or refine the acceptance criteria of an item. If
the Developers feel a high level of uncertainty due to the PO being unavailable, they can
make a best guess and the Sprint starts nonetheless.

It is permissible and sometimes beneficial to invite external experts or stakeholders to parts

of Sprint Planning for specific informational purposes, but the core planning and
commitment belong to the Scrum Team.

An earlier version of the Scrum Guide prescribed the practice of placing one improvement in
the Sprint Backlog. It is not prescribed anymore, but can still be valuable.

The Sprint Goal

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint
Backlog. It is the single objective for the Sprint and a commitment by the Developers.
The Sprint Backlog

It is composed of the Sprint Goal (why), the set of Product Backlog items selected for the
Sprint (what), as well as an actionable plan for delivering the Increment (how).

It is a plan by and for the Developers. It is a highly visible, real-time picture of the work that
the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.
Consequently, the Sprint Backlog is updated throughout the Sprint as soon as possible after
new work or future decomposition of work is identified.

The Sprint

The heart of Scrum is a Sprint, a timebox during which a done, useful, and valuable working
product Increment is created. The Sprint is a container for the following timeboxed events :
Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

A first Sprint requires no more than a Scrum Team and enough ideas to potentially complete
a full Sprint. Sprint 0 and release sprints are not allowed in Scrum. During a Sprint, the
Developers should not be interrupted and the Sprint Goal should remain intact.

The length of a Sprint is how often the business needs to inspect the Increment and adapt
the direction based on new information. It should be one month or less : short enough to
keep the business risk acceptable to the Product Owner, and to be able to synchronize the
development work with other business events. This timeboxed fixed length of the Sprint helps
minimize risk by creating the opportunity to validate assumptions using feedback from users
and the market, allowing Scrum Teams to inspect progress toward the Product Goal and
decide whether to pivot or persevere.

-​ How much work must the Developers complete for each Sprint?
Enough so that the Increment meets the Definition of Done. During the Sprint, the selected
Product Backlog items may be clarified and re-negotiated between the Product Owner and
Developers as more is learned.

-​ When does a Developer become accountable for the value of a Product Backlog
item selected for the Sprint?
All members of the Scrum Team share in the accountability for creating value every Sprint.
No individual Developer can claim ownership over an item as this would block
communication and collaboration.

-​ Who is responsible for managing the progress of work during a Sprint?

The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to
inspect how progress is trending toward completing the work in the Sprint Backlog.
 -​ During a Sprint, a Developer determines that the Scrum Team will not be able to
complete the items in their forecast. Who should be present to review and adjust
the Product Backlog items selected?
During the Sprint, scope may be clarified and re-negotiated between the Product Owner and
the Developers as more is learned. It is important to be transparent when challenges arise
since ultimately the entire Scrum Team is accountable for creating a valuable, useful
Increment.

-​ The CEO asks the Developers to add a "very important" item to a Sprint that is in
progress. What should the Developers do?
They can discuss the item with the other members of the Scrum Team and ask the executive
to work with the Product Owner. No one external to the Scrum Team can force changes on
the Developers and no changes should be made that endanger the Sprint Goal.

-​ When might a Sprint be cancelled?

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has
the authority to cancel the Sprint.

A new Sprint starts immediately after the Sprint Retrospective of the previous Sprint.

The Daily Scrum

The Daily Scrum is always a 15-minute event, held at the same time and place each day to
reduce complexity. Because it is a short event, the timebox is not influenced by the Sprint
length. The Scrum Master ensures that the Developers have the Daily Scrum and teaches
them to keep it within the 15-minute timebox.

The Developers are responsible for conducting the Daily Scrum. Only the people doing the
work described on the Sprint Backlog need to inspect and adapt at the Daily Scrum. If the
Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they
participate as Developers, and then need to be at the Daily Scrum.

People outside the Scrum Team are not allowed to participate, nor use the event to check
progress. However, external stakeholders are allowed to listen in for the sake of
transparency. In that case, the Scrum Master can instruct them to remain quiet and refrain
from asking questions or making comments.

Product Backlog Refinement

It is the act of adding detail, estimates and order to Product Backlog items for upcoming
Sprints. Not an official Scrum event, it is an ongoing process that takes no more than 10% of
the capacity of the Developers. Including the Scrum Team in Product Backlog refinement will
reduce the uncertainty before running the next Sprint Planning.
The Sprint Review

This event is generally considered an informal meeting or a working session, rather than a
formal one. It is when the Scrum Team and stakeholders inspect the outcome of a Sprint and
adapt the Product Backlog. The Increment reviewed at the event must meet the Definition of
Done. Attendees collaborate on the next things that could be done to optimize value, which
is processed into an updated Product Backlog.

The typical key stakeholders for the Product identified by the Product Owner are :

-​ the people responsible for making the funding decisions for the product development
effort
-​ the people who actually use the product under development
-​ the people responsible for paying to use the product

Even though the Scrum team is allowed to interact with the stakeholder any time where it’s
valuable to have their input, the Sprint Review is the only event where the key stakeholders
are allowed to participate.

The Sprint Retrospective

This reflection event can be compared to the use of a “lessons learned meeting” and
concludes the Sprint. It is an opportunity for the Scrum Team to inspect itself and create a
plan for improvements to be enacted during the next Sprint. Their attendance is mandatory
and people outside the Scrum Team are not allowed to participate. Appropriate topics for
discussion in this event are :

-​ Team relations
-​ How the Scrum Team does its work
-​ Definition of Done

As an outcome of the Sprint Retrospective, the Scrum Team should make sure the Sprint
Backlog for the next Sprint includes at least one high priority process improvement.

The Product Owner

The Product Owner is accountable for maximizing the value of the product and the work of
the Scrum Team. This value and how it’s measured are likely to vary across products and
organizations. The PO will monitor and share progress of the Product Backlog by using any
practice based on trends of work completed and upcoming work.

A Product Owner engages early and often with stakeholders, representing them to the Scrum
Team, which includes representing their desired requirements in the Product Backlog.
However, to limit the disturbance to the development progress and keep focus high, the
stakeholders have a formal role in the process at the Sprint Review only.

The PO gains product vision by consulting a variety of sources : the Developers, customers &
prospects, sales executives & leaders, CEO… They measure the progress of product releases
thanks to awareness of competitive research, marketplace, customer feedback, forecasting
& feasibility.

-​ Who should know the most about the progress toward a business objective or a
release, and be able to explain the alternatives most clearly?
The Product Owner is accountable for effective Product Backlog management. That includes
developing and communicating the Product Goal, creating and communicating Product
Backlog items, ordering the Product Backlog, and ensuring that it is transparent, visible and
understood. For the PO to succeed, the entire organization must respect their decisions.

The Product Owner is not only accountable for development and release of a product, but
also the cost of maintaining and operating the product over its lifetime : they will take into
account all investments required to conceive, develop, operate and maintain the product. In
order to make investment decisions, the Product Owner is likely to look at the total cost of
ownership of the product being built, which can be affected by the Definition of Done..

The technical debt limits the value a PO can get from a product : it reflects some extra
development work, reduces the velocity at which new functionality can be created, causes a
greater percentage of the product’s budget to be spent on maintenance of the product,
compromises long-term quality of the product, creates uncertainty, could lead to false
assumptions about the current state of the system, and is a real risk which can genuinely be
incurred.

When a product grows, it is quite possible that the PO will get help from other product
managers and others in the organization who interact regarding the customers facing
activities and knowledge of the product marketplace. While it is fine for the Product Owner
to be aided by the aforementioned people, it is not acceptable for the PO to attempt to
proxy or outsource their PO Scrum Team duties.

The Scrum Master

The Scrum Master helps the Scrum Team become more effective in several ways :

-​ facilitating and removing impediments

-​ promoting and supporting Scrum within the team
-​ helping the Scrum Team understand the need for clear Product Backlog items
-​ facilitating Scrum events and stakeholder collaboration as requested or needed

For instance, to start a project, the Scrum Master should ask the Developers to introduce
themselves to each other and tell about their skills and background. The organization as a
whole is coached in its Scrum adoption by other Agile leaders.

The Scrum Master can serve the Product Owner by :

-​ teaching them techniques to improve their collaboration with the Developers

-​ suggesting new collaboration tools
-​ finding techniques for effective Product Backlog management
-​ helping establish empirical product planning for a complex environment
Events and timeboxes

Scrum events are opportunities for inspecting and adapting.

Prescribed events are used in Scrum to create regularity and to minimize the need for
meetings not defined in Scrum. Timeboxed events are events that have a maximum duration.

The Scrum Guide states that the Sprint Planning (8 hours), Sprint Reviews (4 hours) and
Sprint Retrospectives (3 hours) are timeboxed events. For shorter Sprints (less than one
month), the events are usually shorter.

Fixed-length events have both a minimum and maximum duration. Sprints are fixed-length
events of one month or less to create consistency, and the Daily Scrum is a 15-minute event.