Disclaimer

The author or any organisation the author represents

at the time of writing this book, is not a certifying body
for any Scrum.org certifications and has no role or
influence in granting any of the Scrum.org
certifications. This book serves as guidance material
to help readers prepare for PSPO I™ and PSPO II™
assessments.

The terms Scrum Open, Professional Scrum™,

Professional Scrum Master™, Professional Scrum
Product Owner™, PSM, PSM I, PSM 1, PSM 2, PSM II,
PSPO I, PSPO 1, PSPO II, PSPO2 etc. is the protected
brand of Scrum.org. This book is neither endorsed by
nor affiliated with Scrum.org. This book uses content
adapted from the Scrum Guide from scrumguides.org
and is under the Attribution ShareAlike license of
Creative Commons.
 Copyright © 2021
All rights reserved. No part of this publication may be
reproduced, stored or transmitted in any form or by any
means, electronic, mechanical, photocopying, recording,
scanning, or otherwise without written permission from the
publisher. It is illegal to copy this book, post it to a website, or
distribute it by any other means without permission.

First edition
How will this book help you?
Whether you’re a seasoned Product Manager, Product
Owner or are new to the Agile world - there’s always
something new to learn. If you are looking to get
certified as a Product Owner, or need a different
perspective on how to handle practical product
scenarios, this book will help.

This is what you get:

Part 1: All the Scrum basics - Whether you are new,

or need a knowledge refresh, Part 1 will cover the main
points about the history of Scrum, the Roles, Artifacts
and Events. This part is straight to the point but
comprehensive enough to update you with everything
that is Scrum.

Part 2: All about Products and Product Ownership -

What does a Product Owner do? What don’t they do?
How do they get a good product out in the market?
What tools can they use to help them? This part
answers all these questions, and more! Not only does
it cover the Product Owner fundamentals, but it
includes short descriptions of business and marketing
concepts that make a product succeed. This section
exceeds the basics of Product Ownership - you’ll have
a good grasp of everything from product strategy to
product metrics, market personas and more!

Part 3: All about the action - The day to day of a

Product Owner, Planning releases, Participating in
Scrum Events, Managing the Product Backlog,
Requirements gathering - it’s all there! We’ve even
included a bonus section that goes through the most
common challenging situations that a Product Owner
encounters, and how to tackle them.

Reading this book will help you get through the first
and second PSPO™ certifications.
Acknowledgements
A special thank you goes out to the people in the Agile
community that have helped write and review this book:

Antony Nizamoglou
Matthew Croker
Ivan Traveso
Table of Contents
How will this book help you? 4

Acknowledgements 6

Table of Contents 7

Glossary 11

Part 1 13

Agile and Scrum Fundamentals 13

Chapter 1 14
A little background about Agile 14
Chapter 2 28
Scrum Theory 28
Transparency 29
Inspection 29
Adaptation 29
Roles and Responsibilities within Scrum 32
Scrum Master (SM) 33
Developers 35
Product Owner (PO) 37
Artifacts within Scrum 39
Product Backlog (PB) 39
Sprint Backlog 39
Increment 40
The Increment 41
 Events Within Scrum 42
Chapter 3 50
Estimations and Velocity 50

Part 2 60

Product Ownership 60
Chapter 4 61
Product Manager/ment and Product
Owner/ship 61
Strategic (leading to Product Vision,
Strategy and Roadmap): 65
Scrum: 66
Tactical: 67
Chapter 5 68
The Product Owner 68
A PO does not manage teams 69
Chapter 6 79
Product Vision 79
Product Strategy - How do we get there? 83
Chapter 7 88
Tools for Business and Product Level Strategies
88
Miles and Snow’s Organisational Strategies 99
PEST and SWOT analysis 100
4Cs Marketing Mix 100
Product Life Cycle Framework 103
BCG Growth Share Matrix 105
Diffusion of Innovation 108
 Chapter 8 111
Product Roadmap 111
GO (goal-oriented) Product Roadmap 112
Now-Next-Later Product Roadmap 114
Product Value 116
Value Metrics & Evidence Based Management
(EBM) 117
Thoughts and Predicaments 121
Digging Deeper 122
Chapter 9 127
The EBM Guide 127
KVA 1 - Time to Market (T2M) 127
KVM 2 - Current Value (CV) 128
KVM 3 - Unrealised Value (UV) 129
KVM 4 - Ability to Innovate (A2I) 131

Part 3 135

Tactical Product Ownership 135

Chapter 10 136
Validation, Interaction and Feedback Loops 136
Empiricism and Product Ownership 138
The Product Owner Scrum Event Matrix 140
Product Owner Relationships 143
Acceptance Criteria and Definition of Done 146
Chapter 11 149
Requirements 149
Nonfunctional requirements 153
 A little about User Stories 154
Product Backlog Management 158
How does this affect the Product Backlog? 160
What does “Product Backlog management”
include? 161
Chapter 12 163
Release management 163
Release Planning 164
Forecasting 170
A note about Velocity: 172
Releases and Risk Management 173
Release Frequency 177
Releasing too often 178
Chapter 13 180
A PO's Tricky Situations - What to do, and when
to do it 180
Credits 188
Glossary
DoD - Definition of Done - A quality criteria that
determines whether an increment can be released
Done - Consistent with the definition of done
Increment - The increment holds a number of PB
items that are ‘done’ at the end of the Sprint plus the
value of the increments of all previous Sprints.
PB - A Scrum artifact known as the Product Backlog
that includes Product Backlog Items which describe
the requirements of the product
PBI - Product Backlog Item
PM - Project Manager
PM - Product Manager
PO - Product Owner
Refinement/Product Backlog Refinement - the act
of adding detail, estimates, and order Product
Backlog items
Sprint - A period of time usually one month or less
during which a "Done", useable increment is created
Sprint Backlog - A Scrum artifact that includes
selected Product Backlog Items, plus their plan for
delivery as an increment for the Sprint
SM - Scrum Master
Waterfall - A traditional project management
process that is based on different phases
 Part 1

Agile and Scrum

Fundamentals

❖ Read this section if you’re unfamiliar with Scrum, or

just need a recap about Scrum theory
Chapter 1

A little background about Agile

In 2001, a ski-resort getaway in Snowbird Utah

hosted the creation of what is known today as the
'Agile Manifesto1'. Seventeen software professionals
gathered to discuss different software
methodologies such as Extreme Programming, or
XP in short. They wanted to share their approaches,
ideas and experiences - but after discussing their
interests in detail, they decided to go much further
than that. They decided to write and publish a
document that establishes the common ground of
the software development community. The
manifesto was a 'call to arms' of what these
seventeen professionals believe in, but also what
they oppose.

The result was a set of values that went on to define

the core of Agile:

1
"Manifesto for Agile Software Development."
https://agilemanifesto.org/. Accessed 10 Jun. 2020.
 Quoted from the Agile Manifesto:

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

● Individuals and Interactions over processes and tools

● Working Software over comprehensive
documentation
● Customer Collaboration over contract negotiation
● Responding to Change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

These values sound well and good, but it is

important to understand the reasoning behind these
statements. The values do not mean and should not
imply that processes, tools, documentation,
contracts and plans are not required. They are just
not meant to stand alone. These values recognise
that projects involve multiple people each having
different skills and roles, that come together to
achieve a goal. The manifesto recognises that what
matters most should not be overshadowed by
tedious processes, documents, contracts or plans.

Pick one set of values, and think if you can relate

one of your previous experiences to these values.
Try to understand why and how the value on the left
is more impactful to the project output.

The Manifesto for Agile Software Development also

has twelve principles:

1. Customer satisfaction by early and continuous

delivery of valuable software.
2. Welcome changing requirements, even in late
development.
3. Deliver working software frequently (weeks rather
than months)
4. Close, daily cooperation between business people
and developers
5. Projects are built around motivated individuals,
who should be trusted
6. Face-to-face conversation is the best form of
communication (co-location)
7. Working software is the primary measure of
progress
8. Sustainable development, able to maintain a
constant pace
9. Continuous attention to technical excellence and
good design
10. Simplicity—the art of maximising the amount of
work not done—is essential
11. Best architectures, requirements, and designs
emerge from self-managing teams
12. Regularly, the team reflects on how to become
more effective, and adjusts accordingly

The manifesto is available online at

agilemanifesto.org. It's handy to bookmark this link
since most Scrum certifications directly reference it.

These principles are the basis of the values, showing

a scenario that boosts project success. However, in
practice, these principles are far from easy to
uphold, and require a learning journey that brings
the organisation closer every single day. This book
also includes practical “how to” scenarios that can
be used in the working environment - more in Part 3
- Tactical Product Ownership.

Before diving into Agile, it’s good to understand

what is known as waterfall - a traditional project
management methodology, to have something to
compare with:

A waterfall is an area where water flows over a

vertical drop or a series of steep drops in the course
of a stream or river.

They're also beautiful to look at, but if you cluelessly

dive into one, there could be consequences.

The waterfall methodology is a traditional approach

that splits a project life cycle (i.e. the period between
when the project starts and ends) into 'phases', each
phase occurring once. Typically, the waterfall phase
looks like this:

Each phase is only done once, and cannot start

before the previous one is finished. Now let's put that
to a practical scenario and see how this could be
troublesome. If a client is expecting a finished
product in May and analysis was done once in
January, the only time that the client can test their
analysis is in April - four months into the project,
after all of the development has been completed.
During the testing, the client notices an error,
miscommunication or simply insists that a feature
needs to be changed due to new market demands
and regulations. That feature is core, and impacts
the majority of the software architecture. The
Developers will need an additional month to change
the architecture, and another to develop the feature.
Blast! The software company now has to start over.
Four months of sunk costs. Not only that, but the
client is shocked when they are told to wait another
two months to test the new feature.

Why did this happen?

● Analysis was not validated early enough. Testing

only happened once, assuming that all the
previous phases were done perfectly
● Development proceeded based on one version
of design - the initial one, without it being
validated
● No one checked with the client before the testing
phase started, they placed their full trust on the
analysis preparation work that was done in
January
● The project was not prepared for things that can
go wrong since risks were not evaluated
● Communication between the people involved in
different phases was minimal and only occurred
at the points of handover

What should complex projects be prepared for?

● People making mistakes

● Changing requirements and priorities
● Shifting technologies
● Delays
● Changes in deadlines

BUT WAIT!
Here’s an important disclaimer:

In some types of projects - typically simple

straightforward ones that might have even been
done many times before, waterfall can make sense.
When it does make sense, problems are scarce and
can be easily fixed - and that's fine.

Although you’re probably here because projects are

complex, things go wrong, surprises happen and you
want to learn what Agile and Scrum are all about.
 THIS is where AGILE
practices come into
play.

So what is the difference between waterfall and

Agile? In a nutshell, it's the iterative and incremental
process, that provides more opportunities to release,
validate and improve:

Value delivery happens multiple times and in shorter

time spans, instead of happening once after the
total cost and time investment. In Scrum, each cycle
is known as a Sprint.

An iterative process means that features are

developed, validated and released in multiple cycles.
During each cycle, feedback is communicated
throughout the Scrum Team and stakeholders. Any
issues found with the work being done can be
surfaced earlier, allowing more time to adapt. Risks
and changes are communicated more often with the
client, allowing the team to become more responsive
to the market.

On a higher level, this is where Scrum comes in.

Whilst Agile is a guideline and way of work, Scrum is
a framework (that is, just one of the Agile
frameworks). There are others that go beyond the
scope of this book, but are available for reference:
Agile also incorporates different practices like test
driven development (TDD), refactoring, pairing etc.
These all support the Agile manifesto in order to
produce high quality products that can be budgeted,
developed, tested, and changed more easily.

Now that you're familiar with Agile practices, think

about how easy or difficult it will be for your
organisation or team to follow it.

If you answered that

it’s easy:
Your organisation is pretty flexible to change, but
there's always more improvement to be done.
If you answered that it’s
hard:
Like any other change, becoming Agile requires a
transition period, a change in systems, practices and
culture. In some cases, you will require buy-in or sign
offs to introduce a new methodology to the
company.
The definition of Scrum - summed up:

Scrum is based on the theory of

empiricism, which states that knowledge
comes from experience and that ideas
should be based on empirical evidence. It is
also founded on lean thinking, to remove
waste and increase focus on what really
matters. To maximise knowledge and
evidence, Scrum enables more points of
feedback through the iterative and
incremental approach. This way, validation
happens more often, so if (or when)
something goes wrong, the team is
informed after a shorter period of time.
Furthermore, Scrum incorporates
checkpoints through Scrum events, thus
providing multiple opportunities for teams
to communicate and collaborate. Most
importantly, product knowledge is
continually enhanced from time-boxed
Sprints since customer feedback is
obtained frequently when increments are
released.

When an organisation decides to adopt the Scrum

framework, expectations include the following:

● Transparent and regularly communicated risks

with the client
● Handling client changes more proactively
● Decreasing non-value-added waste.
● Managing risk exposure through early and
frequent product reviews
● Making funding and investment decisions based
on releasing early and often to have regular
Sprint outcome inspections and understand what
value is being delivered through the investment

Scrum also addresses the following risks that are

common to most projects:

● Complexity and unpredictability of requirements

● Stability, sustainability and complexity of
technology
● Working relationships and motivation of the
people involved
● Timescale of planned work
It encompasses ideas from different schools of
thought including time management,
entrepreneurship and operations management - all
tailored to suit complex environments.
Chapter 2

Scrum Theory

There are three pillars that represent the empirical

process control within Scrum theory, which are
transparency, inspection and adaptation.

Scrum Pillars
Transparency
The Scrum artifacts are designed to be transparent
for a good reason; to allow anyone with an interest
in the product and Sprint to be able to inspect,
analyse and give feedback. Every single person in
the Scrum Team should be able to know Why they
are doing what they are doing, What impediments
there are and Where they are going.

Inspection
Scrum also incorporates checkpoints that give the
opportunity for inspection of the process, product
and anything else that can be improved. The events
included in Scrum are suitable times for Inspection,
where discussion and collaboration is encouraged
(within the reasonable time boxes of course!).

Adaptation
Through Transparency and Inspection, people are
able to learn, constantly improve themselves and
their contribution to the product. They are able to be
more confident with forecasting their efforts and
releases, and more importantly, they learn from
things that went wrong to prevent them from
happening again in the future.
 The three pillars are the essence of Scrum, and as
you continue reading, you will notice how everything
revolves around these three pillars of Empiricism.

Scrum Values

● Commitment - Commitment to the Sprint Goal,

to the work that the Team wants to get done, to
the Team, to delivering value and to continuous
improvement. Following through on what you
wish to achieve helps with building trust with
team members and stakeholders.
● Focus - Focusing on one thing at a time means
delivering an outcome with higher quality. Scrum
does not recommend having Developers
working on different products, Sprints or teams
concurrently.
● Openness - Impacts trust between members of
the Scrum Team and also between the
stakeholders and the organisation. It induces
collaboration and creates transparency around
challenges that are met during product
development. It's important for the Scrum Team
to be open and honest about their tasks,
accomplishments, impediments and progress.
● Courage - Courage to speak up, expose
impediments and blockers, to remain
transparent, to communicate differing opinions
and ideas and to trust others.
 ● Respect - Respecting and following up on the
decisions that were taken as a team, respecting
their estimations without pushing them to work
long hours and burning out. Respecting opinions
and different perspectives. Respecting
colleagues and each other affects employee
behaviour as a whole, builds a solid team culture
and also improves employee happiness and
success.

These values are not just needed in the context of

Scrum, but in any functioning organisation.
Roles and Responsibilities within Scrum

Scrum includes three main roles. If you plan on

taking a Product Owner related certification, you
might see questions that include roles like ‘Project
Managers’, ‘Business Analysts’, ‘Testers’ and so on.
Scrum does not formally define any of these titles.
Scrum Master (SM)

● A facilitator, coach and Scrum guru. The primary

purpose of the SM is to educate everyone about
Scrum practices, principles and values.
● They are there to provide guidance and help out
the Developers and PO when they get stuck with
impediments.
● They possess leadership skills, but are
knowledgeable about the product environment
and the market that it serves.
● They are change agents and are willing to push
the wheel of change to continually improve
internal processes.
● The SM can be thought of as a mini-Chief
Operations Officer (COO).
Developers

● In Scrum, the Developers are cross-functional

and do not have specific roles or titles regardless
of the type of work that they perform. Roles
such as ‘Testers’, ‘Business Analysts’ and
‘Developers’ are not defined in Scrum.
Cross-functional does not mean that everyone in
the team does everything. There are still meant
to be skill specialisations, the main point is that
 the team understands the product and the
development life cycle as a whole.
● The ideal number of team members defined in
the Scrum Guide2 is 3-9 members, otherwise,
there may be risks when it comes to effective
communication.
● The Developers decide how to build the features
of the product. At the end of the Sprint, they are
responsible for the quality of what was delivered.
● The Developers are responsible for estimating
items that are on the Product Backlog.

2
"The Scrum Guide - Scrum.org."
https://www.scrum.org/resources/scrum-guide. Accessed 9
Jun. 2020.
Product Owner (PO)
(more on the definition in following chapters)

The one and only

Value Maximiser
Also:
● A product expert that is in close contact with
stakeholders.
● Understands the work that needs to be done to
increase product value and translates the needs
of the product to the Developers.
● Responsible for Product Backlog (PB)
management and Releases.
● A mini-Chief Enterprise Officer (CEO) .
● Even though the Scrum Guide does not specify a
lot of details about the PO, the role is strongly
linked to Product Management, Marketing,
Business Development and to some extent,
Project Management.

Together, the Scrum Master, Developers and

Product Owner form The Scrum Team.

● The recommended Scrum Team size is

typically ten or fewer people.
Artifacts within Scrum

Product Backlog (PB)

The one source of truth for product requirements,
planned features and their priority. These may look
like use cases, user stories, tasks or any format that
makes the requirement understandable. The PB is
managed by the PO and is accessible by anyone
that is involved or interested in the product. The PO
is responsible for managing the PB, and ensuring
that requirements are clearly defined and prioritised.
More about the PB is available in Part 3 - Product
Backlog Management .

The commitment towards the Product Backlog is the

Product Goal. This describes the next long-term
objective for the product, which may be the
upcoming goal as defined in the Product Roadmap.
More about this in Chapter 8.

Sprint Backlog
During the Sprint Planning event, the Developers
analyse the PB and plan the features that they can
develop within the Sprint to meet the Sprint Goal.
When this happens, the feature details are
transferred from the PB to the Sprint Backlog. The
Sprint Backlog is owned and managed by the
 Developers. The Developers update the Sprint
Backlog throughout the Sprint, and the Sprint
Backlog emerges during the Sprint as more is
learned. It's the best source for understanding the
progress of the Sprint, the features that are being
worked on and how much work remains to be done
till the end of the Sprint. Like the PB, this artifact is
kept transparent, but is mostly accessed by The
Scrum Team.
The commitment towards the Sprint Backlog, is the
sprint goal. The sprint goal does not change during
the Sprint, as it provides a point of focus for the
team. Sprint goals are meant to have just one target
- not a summary of the entire backlog (it would
otherwise be irrelevant).

Increment
The increment holds a number of PB items that are
‘done’ at the end of the Sprint plus the value of the
increments of all previous Sprints. The final say on
whether an increment is ‘done‘ belongs to the Scrum
Team. The delivery of the increment is an
opportunity to inspect and adapt. Thus, the outcome
of the increment will validate the value that it holds.
The Product Owner then holds the responsibility to
decide on when to release the increment.
The Increment

The commitment towards the Increment is the

Definition of Done: a description that reflects the
standards of the increment that needs to be complied
to. More about the Definition of Done in Chapter 10.
Events Within Scrum

Daily Scrum

● The Developers are responsible for the Daily

Scrum, deciding where and when to hold the
event. The Scrum Master coaches them to own
how and where the meeting is held and to stick
to the 15 minute time box.
● The typical setup of a Daily Scrum includes the
inspection of the sprint progress towards the
Sprint Goal. This is a good opportunity to identify
impediments and discuss the plan for the day.
● If any impediments are identified, they are
normally discussed and tackled after the Daily
Scrum.

Daily Scrum Note

This quick meeting helps the

Developers understand what
everyone is working on, which
means that progress is made
transparent every single day.
This removes the need for extra
meetings. Everyone’s
contribution, delays and
impediments towards the
Sprint Goal are made clear.

TIMEBOX LENGTH: 15 minutes

 OUTCOME: A plan and goal for the day on a Team
level - this includes how the team will coordinate
to achieve it.

Sprint Planning:

The Sprint Planning event includes the following

topics:

Topic i - Defining the Why

The PO explains which business objectives hold the
most value and why they are needed to achieve the
Product Goal. This provides a good basis to set the
Sprint Goal.

Topic ii - Defining the What

The Developers and PO examine the PB to identify
which features should be planned for the Sprint.
They collaborate together to understand priorities
and requirements. The entire Scrum Team will
collectively determine a Sprint Goal after analysing
the work needed. The Developers will discuss and
estimate their effort required for each of the Product
Backlog Items that they will take on during the
Sprint. This is also known as the Sprint Forecast.
During this part, the entire Scrum Team attends.

Topic iii - Defining the How

 The Developers collaborate to discuss the chosen
features, to start understanding how to develop
them to meet the Definition of Done and develop an
increment by the end of the Sprint. The PO is not
required for this part of the event, but should be
reachable if questions need to be answered.
● Note that the Sprint Planning can start even if
there aren’t any fully analysed and defined items
in the Product Backlog. The analysis and further
definition of these tasks can take part during the
Sprint.

TIMEBOX LENGTH: 4 hours for a 2 Week Sprint / 8

hours for a 4 week Sprint.
OUTCOME: A goal for the Sprint, a set of backlog
items and a plan towards achieving the goal.

Sprint Review

● This is the third event, held towards the end of

the Sprint.
● The Scrum Team and stakeholders (can include
clients, customers, users, investors, internal
stakeholders and anyone that is involved in the
product development) are present to
demonstrate the increment and suggest
improvements through collaboration.
● An opportunity to inspect the increment, decide
what to do next and adapt the PB.
 ● Note that although this event is dedicated to
obtaining stakeholder feedback, it is not the only
point during the Sprint where feedback and
communication with stakeholders is done.
Continuous interaction with users and
stakeholders encourages open communication
and helps build customer relationships - it can be
done during the entirety of the Sprint.
● The review is not, and should not ever be
regarded as a gate to releasing value.

TIMEBOX LENGTH: 2 hours for a 2 Week Sprint / 4

hours for a 4 week Sprint.
OUTCOME: Stakeholder feedback, a clearer idea
of which items should be worked on in the next
Sprint, an updated Product Backlog.

Retrospective :

● The last event held at the end of the Sprint.

● The Scrum Team attends this meeting and
inspects what went wrong and what went right
during the Sprint. This event is regarded as a
safe place to discuss anything minor or serious
that hindered the Team’s progress.
● They discuss what can be improved and how to
tackle the issues. Any kind of improvements
apply, including individuals, interactions,
processes, tools and their Definition of Done.
● Solutions are proposed and actions to improve
are addressed

TIMEBOX LENGTH: 1.5 hours for a two week Sprint

/ 3 hours for a one month Sprint.
OUTCOME: Actionable improvements that provide
an opportunity for the Scrum Team to inspect and
adapt.

Entire Sprint Timebox: Not longer than one month

What happens at the start of the Sprint?

● The Sprint kicks off with the Sprint

Planning event, so a Sprint Goal is
created and the Developers forecasts
what work can be done.
● The Sprint Backlog is created.

What happens during the Sprint?

● The Scrum Events take place.

● The work done is based on the Sprint
Goal and Definition of Done.
● The Product Backlog is constantly refined
throughout the Sprint
● The scope of the Sprint may be changed
by the PO and the Developers as long as
the Sprint Goal is not compromised.

What happens at the end of the Sprint?

● The work done is reviewed by
stakeholders and their feedback is
communicated to the Scrum Team
● A “done” increment is prepared and the
PO determines whether it can be
released.
● The team retrospects and suggests
improvements for the next Sprint
Chapter 3

Estimations and Velocity

Any piece of work that is included in the Product

Backlog needs to have a measure of estimated
effort before development on the item begins. Only
Developers (i.e. the people performing work directly
on the item’s development), give the estimate based
on their understanding of the item and its trade-offs.
The measure need not be accurate - its main
purpose is to give an indication of required effort
when compared to the effort of other items (this is
known as relative sizing) and not a definitive
commitment. It is in the PO’s interest to take note of
estimations so that they can use the data to plan
releases - more about this in Release management

Estimations are given when the Product Backlog is

being refined and also during the first part of the
Sprint Planning event. The Developers take each
item, discuss it with the Product Owner, and give
their estimates.

Estimation accuracy depends on:

● The experience of the Developers. Having a
team that has worked together before in
 previous Sprints, means that they have given
their estimates before, and have been able to
compare their initial estimates with the actual
effort that was needed. The more opportunities
they had to compare their estimate, the better
their new estimates. Estimates coming from
newly-formed development teams can be
expected to have a higher margin of error as
before progressing towards a performing3 team.

● Unaddressed Technical debt in the system.

When the system is unstable or badly designed,
adding and changing features often result in
spending more time fixing affected components
and less time working on the actual new feature.
This also influences the team’s predictability.

● Complexity. Predicting effort when using new

technology or developing a significantly complex
feature - especially those that require
experimentation, are better handled using a
ballpark figure, since the level of uncertainty is
high. Methods such as T-shirt sizing (XL, L, M, S)
are a good way of giving a rough effort
indication in these cases. Complexity can also be
present in:

3
Tuckman, Bruce W (1965). "Developmental sequence in
small groups". Psychological Bulletin. 63 (6): 384–399.
doi:10.1037/h0022100. PMID 14314073.
 ○ Client requirements
○ Market factors
○ Existing system
○ New technology
○ Workflow
○ Team relationships
○ Networks of communication

● Subjectivity. Optimistic estimates only consider

the best-case scenario, which does not regard
risks to the delivery. On the other hand,
pessimistic estimates consider the worst-case
scenario and can lead to inflated estimates. An
informed PO will be aware of the assumptions
that are taken when estimates are given. In the
Release management section, the Release
Burndown Chart is discussed in more detail and
shows how to plot the best case and worst case
scenarios in the same chart. This can give a
better idea of the average overall estimates at a
glance.

Methods for measuring estimates vary and Scrum

does not require any specific method. Some common
methods include:

● Numeric Sizing / Story Points (e.g. 1 -

100)
● T-shirt Sizes (XS, S, M, L, XL XXL, XXXL)
 ● Fibonacci Sequence (1, 2, 3, 5, 8, 13, 21,
34, etc.)
● Planning Poker

The total amount of work that is done within a whole

Sprint is a key metric, known as Velocity. At the end
of the Sprint, the Developers will measure their
velocity by adding up the estimates that were given
for each item that was completed during the Sprint.
 Velocity Calculation:

Items Done during this Sprint:

● Sprint backlog item 1 = 40 points
● Sprint backlog item 2 = 10 points
● Sprint backlog item 3 = 80 points
● Sprint backlog item 4 = 6 points
● Sprint backlog item 5 = 25 points

Velocity: V1 = 40 + 10 + 80 + 6 + 25 =
161

Items Done during Sprint 2 :

● Sprint backlog item 1 = 40 points
● Sprint backlog item 2 = 25 points
● Sprint backlog item 3 = 80 points

Sprint 2 Velocity: V2 = 40 + 25 + 80
= 145

Items Done during Sprint 3 :

 ● Sprint backlog item 1 = 30 points
● Sprint backlog item 2 = 30 points
● Sprint backlog item 3 = 35 points
● Sprint backlog item 4 = 25 points

Sprint 3 Velocity: V3 = 30 + 30 + 35 +
25 = 120
𝑉1+𝑉2+𝑉3
Average Velocity = 𝑛

161+145+120
3
= 142

Eventually, having the data for the velocity of a

number of Sprints, will serve as a good base to
provide estimations of the team’s capacity, by
considering the average velocity per Sprint. For
instance, knowing that the Developers has a velocity
of between 150 and 200 points, shows that a
commitment to delivering 300 points during a Sprint
Planning event is over-ambitious. There are a lot
more metrics to consider when making such an
assumption however, such as measuring the
amount of technical debt, throughput and cycle
time. More information is available in Chapter 9.
Although you may hear that a higher velocity is
generally a good thing, there are major caveats to
this statement:

● Different teams may use different estimation

measures. Team A’s velocity of 20, may actually
mean more effort than Team B’s velocity of 500.
It’s never sensible to compare velocities between
different teams. Only compare velocity of
different Sprints, within the same team.

● If the team has actually delivered a much higher

velocity than usual, consider whether quality has
been sacrificed to make this delivery possible. A
loss in quality can come back as a big hit to the
product and manifest in technical debt,
unsatisfied customers and buggy functionalities.

● Similarly, if the team has delivered a much

higher velocity than usual, consider what has
been delivered in terms of business value. If the
Product Backlog was poorly prioritised, then all
that effort spent during the Sprint may result in
very little business value (e.g. new features that
the customer doesn’t really need).

● With all this in mind, we know that more velocity

is not equivalent to more value. Also:
A higher velocity is NOT
necessarily a good thing.
Last but not least, estimates are not meant to be
precise. Estimates provide a forecast for what the
Developers believe can be finished within the Sprint,
not a commitment for delivery.
Scrum myths

“Scrum is ideal for all projects ”

FALSE: Scrum is best served for complex projects and

helps expose bottlenecks and impediments earlier.

“The start of a Sprint can be

cancelled or delayed at any time”

FALSE: A Sprint always starts exactly after the

previous one ends - even if there are PB items that are
incomplete or unclear there is no such thing as
“between sprints” or “delayed sprints”. A Sprint can
only be cancelled by the Product Owner if the Sprint
Goal becomes entirely obsolete, or if the
organisation’s strategy decides to change in a way
that the product vision does not fall within the
organisation’s future plans. When PBIs are still unclear
during the sprint planning event, the Developers pull in
what they think can be done, then refine and adapt
the items during the sprint. The retrospective then
provides an opportunity to investigate improving
refinement.

“Hardening Sprints help complete

unfinished work”

FALSE: The “hardening Sprint” is not

actually a part of Scrum and can actually harm
progress in the long term. This kind of Sprint is one
that encompasses all undone work coming from
previous sprints. When this happens, it leaves an
opening for work to be poorly planned and poorly
developed. It also essentially minimises the number of
feedback loops and lowers the number of
opportunities for the Scrum Team to learn and adapt.
 Part 2

Product Ownership

❖ Read this section to learn about Product Owner’s

role in understanding the market, and defining the
course of the product through creating Product
Value, Product Strategy and evidence based metrics
Chapter 4

Product Manager/ment and Product

Owner/ship

The responsibilities of a Product Manager and PO

overlap, especially in companies that are
undergoing or have partially moved to using Scrum.
The Product Manager traditionally forms part of the
Marketing branch, working together with Sales and
Advertising. In theory, the role is not as closely-knit
to the functional areas as a Product Owner and is
sometimes detached from the production itself,
since it's more focused on Product Strategy and
Marketing. In today’s world, the definition of a
“Product Manager” role is exceptionally fluid - and
changes depending on the organisation’s size and
industry. Perhaps the most common definitions are
features of their responsibilities, which are:

● Product feasibility and research

● Product Strategy
● Using influence with functional areas to develop
high quality products
Whilst a Product Manager role can fit in a company
adopting Scrum, this role is not formally part of a
Scrum Team.

So what exactly, is the difference between a Product

Manager and a PO?

In Scrum, the ideal scenario is that one product

should have one PO, who fills the entire product
management vacuum. In contrast with some
opinions, the role of a PO is not a level below or on
par with the Product Manager, but is essentially a
Scrumified version of a Product Manager - a
replacement of the Product Manager that adapts to
Scrum values and pillars:

Note

The ideal PO is the sole

responsible person for all the
product management for a
product, thus eliminating the
need for a traditional product
manager
 In practice, there are many variations to this:

● One Product Owner for all products

● One product with multiple Product Owners
● Product Owners doing scribe and requirement
gathering while Product Managers set the
business vision.
● A Product Owner assigned to each product,
reporting to an overarching Product Manager.

These situations of shared responsibility introduce a

number of issues:

● It goes against the concept of having one person

responsible for the product vision, value and
product management - which reduces
complexities and the need to continually re-align
with others with this shared responsibility. This
directly impacts the prioritisation of work that
needs to be done on an ongoing basis - which is
a core and delicate process that the Product
Owner is accountable for.

● Furthermore, multiple owners means that there

will not be anyone that has a complete, holistic
view of the product's value, vision and
stakeholder validation - this easily results in
increased overheads, subjectivity clashes and
unclear product direction.
● Product development can also take a bad turn if
one of the Product Owners is uninformed about
the features that the other Product Owner is
directing. The result is potentially developing
enhancements that derail the product by being
incompatible with the other features - and to top
things off, this could end up being made
apparent during the Sprint Review, regression
testing or worst case scenario after release to
production.

Whilst this can sound overwhelming, it's good to

know that a Product Owner can delegate work
related to the day to day tactics to the Developers

Where does the Project

Manager fit in?
(short answer: in Scrum, they don’t.)

Project Managers are responsible for planning the

projects, predicting associated project risks,
ensuring that the project sustains its forecasted
time, cost and quality and therefore track and
update project documentation as progress is made.
Project managers typically know very little about
the product and do not contribute to its vision - they
can also manage more than one project. Product
Owners are the product and domain experts, who
are focused on the product, on creating customer
value and on satisfying the users’ needs, while
Project Managers are solely focused on project
delivery, meeting deadlines, examining remaining
budgets, updating schedules and so on.

Note that Project Managers are NOT part of a

Scrum team

The responsibilities of a PO in Scrum include the

following:

Strategic (leading to Product Vision, Strategy

and Roadmap):
● Understanding, researching the market and
industry and assessing their appetite for a
product
● Analysing trends for market and segment
attractiveness
● Keeping track of existing and new competitors
● Analysing market threats and opportunities
● Understanding consumer behaviour and buyer
power
● Determining the potential impact of substitute
products or emerging threats
● Understanding the bargaining power of suppliers
● Taking product decisions to increase competitive
advantage
● Ensuring product feasibility
● Managing the product for customer appeal and
maximising ROI
● New product development process decisions
● Negotiating product deliverables and release
dates with stakeholders
● Understanding stakeholder needs and aligning
them with the product strategy
● Positioning the brand, building brand equity and
taking branding decisions
● Driving product launch or taking the decision to
retire a product or feature
● Supporting organisation decisions on pricing,
distribution channels, promotions and digital
marketing
● Reducing technical debt and keeping it to a
minimum

Scrum:
● Supporting the Developers through product
backlog refinement
● Involvement in sprint planning, reviews and
retrospectives
● Contributing to the sprint goal and definition of
done where needed
● Aligning the Scrum Team and stakeholders to
the product vision

Tactical:
● Compiling marketing metrics for trend analysis,
churn analytics etc
● Release tracking
● Compilation of user stories and acceptance
criteria
● Analysing burn down charts and product metrics
Chapter 5

The Product Owner

A commonly disputed topic is the role and

responsibilities of a PO in Scrum. In order to remove
any misconceptions that you may be familiar with
and disassociate them from the Scrum definition, it's
important to define a PO that isn’t fit for purpose (i.e.
the imposter PO).
A PO does not manage teams
In Scrum, the Developers are self-managing - which
means that they, alone, are held responsible for
deciding how the work gets done, estimating
development effort and moving the Product
Backlog items to their Sprint Backlog. Essentially, the
PO manages the Product and prioritises the features
of the product through the Product Backlog and
need not inspect team productivity, or individual
members. Does the customer care about how
productive Developers are, or do they prefer
obtaining a high value from the product?

A PO is neither a scribe nor a proxy

What is a Scribe PO?

Someone that spends the majority of their time
writing requirements, user stories and product
documentation, without taking responsibility for the
content and its formation. PO responsibilities for
deciding priorities, creating a product
vision/roadmap are decided by other stakeholders
or management. The Scribe PO simply notes down
their decisions without interfering, discussing or
negotiating during product discussions.

Why isn’t this fit for purpose?

● The PO role gets buried down and taken over by

stakeholders, endangering core product
transparency and the rule for having one PO for
the product.

● The Developers may have questions about the

product that the PO is unable to answer or take
decisions about.

● The stakeholder may demand feature requests

that fall out of scope of the product roadmap or
the organisation's objectives. Without
negotiation, the product's destiny will be quickly
taken over by another party.

● The PO's role in a Scrum Team will become

undervalued. Conflicting priorities will interfere
with progress towards the sprint goal. Sprint
scope could become subject to derailment.
 Note

A PO can delegate Product Backlog

management to someone that is part
of the Developers, including detailing
Product Backlog items, interviewing
users, engaging stakeholders and
analysing data.

However! The PO is still accountable

for anything that happens in the
Product Backlog.

What is a proxy PO?

Someone that spends the majority of their time
repeating stakeholders/client requirements/
feedback to the Developers and repeating questions
from the Developers back to the
stakeholders/clients. No value is added by the
proxy, they are unable to take decisions and just act
as an intermediary between parties. Understanding
of the content and context could be limited since
they are used to copy-pasting answers and
questions from one person to the other.

Why isn’t this fit for purpose?

● There is no Product Ownership, only echoing of

information
● The importance of the product vision is
diminished
● They are seen as an unnecessary gateway to
the parties that actually hold the information
that is needed

A PO is NOT a Project Manager

Note that when you see the words 'Project
Manager/Management' do not associate it with
Scrum. As discussed earlier, Project Managers are
NOT a part of Scrum. Although they probably do
exist in your organisation, a PM's role is normally
disconnected from the product itself.

So… What is a PO?

A PO IS:
● A value maximiser:
This is perhaps the key default and important
definition that you will see in most material for
Scrum.

● The sole owner of the product:

Multiple POs for one product is a common
anti-pattern
Being responsible for part of the product, a
subset of the system, a set of features or
architectural layer does not comply with the
Scrum definition of a PO. It is possible, but not
ideal, to have one PO for multiple products.

● In 100% control of the Product Backlog (PB):

Complete responsibility of the PB rests on the
PO's shoulders. They can change it whenever
they need to to uphold transparency and ensure
clear descriptions of stories and features. This is
their primary tool that reflects the future of the
product. Anyone in the organisation that is
interested in the product should be able to look
at the Product Backlog and have a clear
snapshot of the priorities and planned features
of the product.

● A PO decides What the product is and Why it's

there, but does not decide How to develop it.
They decide what needs to be implemented and
at what priority, they have a complete
 understanding of the importance of the feature,
the need it satisfies, the value it holds, the risks it
carries and the impact on the product's future.
The PO however, trusts the Developers to build
and develop these features as they deem fit (as
long as they meet the respective acceptance
criteria). While a PO has every freedom to make
suggestions, he/she does not hold the final say
on how to develop or implement a feature.

A PO can decide the “how?” on a strategic level

(only) - for instance, how to make the product
more competitive? How to engage customers?
How to ensure regulatory requirements are met?

● A product and customer expert:

Well-informed about the product's current and
future markets, the product's competitors, user
habits and psychology. They know the product's
history and are capable of building a solid path
towards its future. They know the necessary
ingredients to develop the product, grow it, and
shield it from competition. They are up to date
on current technology trends and habits related
to the product. They understand what influences
the product from an economic, compliance,
regulatory, financial and social point of view.
They understand all dependencies and
interdependencies of what it takes to build the
product, the knowledge and resources required
 (e.g. technical knowledge, business domain
knowledge, PR knowledge etc). They might not
be deeply technical - but can understand what
knowledge is required to actually build and
release the product successfully.

● An entrepreneur, experimenter and visionary:

POs are naturally business-minded and driven.
They are good negotiators and can spot
profitable business opportunities and
investments a mile away. They know what it
takes to keep customers happy through high
product value and reduced waste. They will take
calculated risks to hold experiments for their
ideas, even if they have limited resources. They
are innovative in recognising market
opportunities and driving competitive products
to success, ensuring a right Product-Market fit.
They visualise a successful product, help people
understand its future potential and are able to
see it through. You will typically recognise this in
a good PO because they have probably run a
business before, or are running one (or more) on
the side. They have an understanding of waste
reduction, investment strategies, marketing and
leadership.

● A collaborator and influencer:

POs make time for the Developers to provide
product guidance and explain the underlying
 product rationale. They are skilled negotiators
and thrive to align anyone involved in product
development to the product vision by ensuring
that the product’s future is kept in scope.

● Empowered with decision making:

Decision making is part of the PO’s day to day. In
practice, these decisions have a direct impact on
the outcome of the product and its time to
market. The Scrum Team and stakeholders need
the PO to be able to make informed,
evidence-based decisions in a short amount of
time, without creating dependencies or long
delays. For the Product Owner to succeed, their
decisions must be respected by the entire
organisation.

REALITY: The ideal PO is a rare breed, but they

should always develop themselves towards
this ideal state.
Chapter 6

Product Vision

What defines a product?

A product is anything that can be delivered to a
customer that satisfies their want or need when
consumed, used or acquired.
Conceptually, products include objects and services
that solve problems because of the benefits they
provide and the value that they deliver through
product features and attributes.

Behind each product is its producer who gains from

delivering the product through increased profits, ROI
maximisation, reaching corporate objectives,
company growth, customer retention, increased
share prices and so on.

In Scrum, products are managed as independently

as possible, each having their own separate release
plans - so a 'product' consists of something that is
packaged independently to reduce complexities and
risk.

What defines a product’s vision?

A key responsibility of the PO is the communication,
accountability and maintenance of the product
vision.

Product Vision Characteristics

A Product’s vision can only follow through if

the value it will deliver is evident and if it
promises meaningful impact

❖ It identifies the target user or client

❖ Establishes the core product features

A Product’s vision can only follow through if

it aligns with the product and business
strategy

❖ It is a baseline of the Product Strategy

❖ It is consistent with the company values

A Product’s vision can only follow through if

the team and stakeholders believe in it

❖ Best developed through collaboration with

the Scrum Team and stakeholders
❖ Has the approval of all stakeholders
❖ Allows team members to understand the
clear relationship between their daily
 activities and how it contributes to the
product's future. Each person involved in
any way can understand their impact on
the bigger picture. Thinking about how
each person's involvement makes a
contribution towards this, will empower
them to take the right decisions that are
kept in line with the product vision. An
engaged team and common
understanding helps manage scope creep
and product risks, without deviating away
to something that could hurt the product's
future.
❖ Serves to guide the team(s) and inform
them and the stakeholders about the
product's goal
❖ Serves to align, motivate and create focus
through ubiquitous language
❖ Most of all, needs to be understandable
and frequently communicated

A Product’s vision can only be followed

through if it remains relevant

❖ Evolves and changes as more is learnt

from customer feedback. Think about this
as a 'pivot' situation that occurs with most
start-ups. Initially, a product offering starts
with the intention to serve a particular
 goal, and sometimes finishes with a
completely different goal to better serve
its users
❖ Makes it easier to inspect progress

Note

The Product Vision is the face of the

product’s future. It is what people
look at to understand why the
product is being pursued and what
value it promises to provide.

Fowler 4 gives a great example template on what a

Product Vision should portray

❖ For [final client],

❖ whose [problem that needs to be solved],
❖ the [name of the product]

4
"Write the Product Vision - Martin Fowler." 5 Apr. 2017,
https://martinfowler.com/articles/lean-inception/write-pro
duct-vision.html. Accessed 2 Aug. 2020.
 ❖ is a [product category]
❖ that [key-benefits, reason to buy it].
❖ Different from [competition alternative],
❖ our product [key-difference].

Product Strategy - How do we get there?

Product strategies will greatly depend on the type of

product and market that is being operated in. For
instance, take a niche, one-of-a-kind item that has
been developed through gaining intellectual
property as an example. Pioneering organisations
can benefit from capitalising on the early
advantage. However, having an innovative product
could be subject to takeover by companies that can
quickly copy and produce it for less.

In another scenario, the product could be a

long-term bespoke service that is customized per
client. The benefits that the consumers would obtain
are specifically tailored to their needs, providing an
opportunity to build rapport and gain a good
foothold on target clients. Obtaining initial client
trust may pose as a challenge without the right
promotion in place.

There are critical questions that need to be

answered before and during a product’s
development journey. The following list is extensive,
but covers a good number of points to consider
before and during product development.

Product Concept:
● What core benefits will the product provide? How
can the product be differentiated from other
similar products in the market?
● What key features will the product consist of?
● What kind of packaging and warranty will it
include?
● What auxiliary services will it have (maintenance,
training etc)?

Pricing:
Comparing investments and pricing strategies
against the value delivered gives information that
can be used to refine future investments.
● What is the revenue objective? When is the
product expected to break-even?
● What is the estimated demand for the product?
● How sensitive is the product’s demand?
● How do the product costs and prices compare
with its competitors?
● Can costs be reduced without sacrificing quality?
● How do competitor prices differ in different
geographic regions?
● Can the customer’s perceived value be used as a
guide to price the product?
● Can discounts and offers be used to encourage
demand?
● Can there be economies of scale to benefit
from?

Distribution
● Which channels of consumption will be used for
the product to reach the consumer?
● How can the product reach the consumer in a
more convenient way?
● How many institutions are involved in the
delivery of the product? (e.g. The product could
be sold through an online platform, or could be
stored in a third party’s warehouse)
● Do the values of the retailer match the values
that the product portrays?
● If a third-party ecommerce website is used to
sell the product, can the product’s sales be
impacted by poor website user experience?
● How many different platforms should the
product be shown and sold in?
● Does a sole product platform lead to too much
reliance on one platform?

Promotion
● How can the organisation’s branding support the
product’s promotion?
● Which promotion channels are ideal and
effective?
● What kind of promotions will ensure customer
loyalty?
● Does the product depend on word-of-mouth
advertising?
● How can each promotion be developed to
remain ethical, reflect good taste and values?

Customers & Market

● What is the target market of the product?
● What is the product’s customer persona?
● What is the expected consumer behaviour of the
targeted customer persona?
● Will consumers have high switching costs if they
switch over from a competitor’s product?

Suppliers & key partners

● Who are the key suppliers and partners and how
much do we depend on them?
● What kind of relationship is held with them?
● What are their long-term plans and how can
they impact the product’s development?
● Who are the supplier’s key contact people and
what could happen if they do not remain in their
current position?
● Are there bottlenecks in the suppliers’ delivery
that impact the product’s development?

Resources and Team

● What kind of equipment, tools and licenses are
needed to develop the product?
● What are the skills of the product’s key
personnel?
● Can a learning path be planned for team
members who wish to develop existing or new
skills?
● How can Team happiness be improved?

Risks, external forces and contingencies

● Is the product dependent on external events
such as weather, fashion or season?
● How are competitors innovating and how fast do
they respond to consumers?
● Which consumer trends could impact the
product vision?
● What shifts in technology could benefit the
product?
● Does the product have any regulatory or legal
requirements?
Chapter 7

Tools for Business and Product Level

Strategies

Strategies can be made at different levels and

contain specific focus points based on the product
and its environment. They are shaped by consulting
several frameworks and tools to obtain a solid
starting point. This section explains a collection of
tools that have been built by strategic thinkers and
marketeers.

Consumer Behaviour

If product value is mainly derived from its consumer

perceived value, then gaining an understanding of
current and potential consumers is needed to make
product decisions and prioritise items in the product
backlog. Creating a ‘persona’ for the target
customers of the product helps with:

● Understanding the needs of specific groups of

users
● Creating a hypothesis about the product’s future
value
● Better understanding of the product’s Unrealised
Value
● Analysing what are customer “no-gos”
● Understanding which features are valued the
most

As the product begins to be adopted by more and

more consumers, divisions may surface between
them, creating groups of users, and thus, more
personas. Identifying these personas may provide
an opportunity to create specialisations or different
versions or advertising for the product that appeals
more to targeted groups.

This can be achieved through consistent direct

communication with end users.
 Case Study: Target’s customer targeting 5 :

Large retail outlets often collect data

about their consumers in order to
create a targeted advertising plan.
Analysing a user's purchase history,
product views, time spent on the
organisation’s website or store, reveals
attributes that are useful to
marketeers.

In the field of Data Mining, a task

called ‘clustering’ effectively splits
user data according to their attributes,
creating different user profiles for the
organisation to deliver their products
to. More prediction techniques are

5
"How Target Figured Out A Teen Girl Was Pregnant Before
Her ...." 16 Feb. 2012,
https://www.forbes.com/sites/kashmirhill/2012/02/16/how-
target-figured-out-a-teen-girl-was-pregnant-before-her-fat
her-did/. Accessed 8 Jun. 2020.
also being used in the field of Machine
Learning, using sophisticated
algorithms to analyse historical
patterns and predict user behaviour
with more accuracy.

In 2012, the large retail corporation

Target developed a method that could
identify whether a buyer is expecting
to have a child in the coming months.
They could also predict the mother’s
due date, and were using this
information to send coupons for
products related to the specific stages
of pregnancy. Whilst this method was
effective at getting parents to-be to
buy more of Target’s products, one
man, a father of a highschool girl, was
quite unhappy.
Barging into the store, he demanded to
know why the company was sending
his daughter pregnancy product
coupons, and whether they were trying
to persuade her into having a baby.
Shocked, the Target employee
apologised.

A few days later, the employee called

to apologise again, and the father
revealed, after having a chat with his
daughter, that she was hiding the fact
that she was pregnant.

This story says a lot about how

precise customer targeting can be,
however POs need to remain
mindful about qualitative customer
factors such as privacy, values and
ethics.
Business Model Canvas

The Business Model Canvas is typically used in

startups to document new proposals or initiatives. It
consists of a sectioned template and is designed to
get people to discuss, think and describe the
following business features:

● Key partners
● Key Activities
● Key Resources
● Value propositions
● Customer relationships
● Customer Segments
● Channels
● Finances (costs/revenue)

Remember that:

POs are entrepreneurial

and experiment with new product propositions. This
framework can help with drafting product ideas.

Pros:
● Can be quickly drafted
● Provides holistic overview of business building
blocks
● Easy to use in a team-based hands-on workshop

Cons:
● Very high level and should not be used as the
final strategy, but as a starting point
● Leaves out the planning/roadmap aspect in
terms of timelines
Porter’s 5 competitive forces6

Competitive forces depend on the product and

industry and explain why some products can be
consistently more profitable than others. As value
maximisers, POs require a good level of
understanding of the market forces that can impact
potential product value.

6
"Competitive Strategy, by Michael E. Porter. New York: Free
...." https://www.jstor.org/stable/258056. Accessed 1 Jun.
2020.
Threat of new entrants: How easy is it for potential
competitors to emulate the product offering and
compete with the product? Can the knowledge and
resources to develop the product be obtained
easily? If the product offering has strong cost
advantages or specialised knowledge, these can
serve as barriers to entry for new competitors and
thus help defend its position in the market.

Threat of substitute products:

In the field of economics, the utility theory describes
how logical consumers demand goods and services
based on the utility function that represents
individual preferences beyond the explicit monetary
value of those goods or services. It calculates how
much someone desires something, and it is relative
to different choices. Consumer behaviour in
economics is based on the following problem: "As a
consumer, how should I spend my money in order to
maximise my utility?" .

In the context of product value, consumers seek to

maximise the product value they get, for every
dollar they spend. Therefore, if a product’s value per
dollar of its price is too low, consumers will simply
switch to an alternative that yields more value to
them per dollar.

Substitute products are any other products from a

different industry that can satisfy the same
customer need. If these products exist, then changes
in their price can influence the demand of the
product offering, since consumers may find it easy
to switch between these products.
For instance, consumers may replace coffee with an
energy drink, even though they belong to different
industries. Since they both satisfy the consumer
need of providing caffeine and energy, consumers
often substitute one with the other.

Bargaining power of suppliers:

Suppliers may be a hidden driving force of the
market, especially if supply is limited. Obtaining
resources at a low cost may be the key to having a
profitable product.

Bargaining power of buyers:

Sometimes, buyers can easily influence the product
delivery and its competitiveness to favour them. For
instance, if switching to a competitor is an easy,
low-cost option, they can threaten to take their
business elsewhere, unless product quality increases,
or cost decreases, or both.
When buyers are few and large, they may have
more leverage and negotiating power over the
product’s future.
Another consideration is the threat of backward
integration, that is, having the buyer develop the
product themselves, alleviating the need for them to
demand the product elsewhere.
Rivalry among existing competitors: Attractive
investment opportunities may lead to a tightly
competitive market, especially if the product is
highly profitable. This may mean that customers
can more easily decide to replace one product with
the other and may be a risky initiative if there is little
product differentiation (i.e. distinguishing product
features that make it stand out from its
competitors).
Miles and Snow’s Organisational
Strategies

In order to survive, companies need to continuously

evolve, which means that their market position
changes constantly. The roles undertaken by the
decision makers of the company depend on the
stage of the company’s evolution.

In 1978, Miles and Snow identified four categories

that define organisational strategy, structure and
process, that are derived from a company’s decision
making. They argued that the way a company
tackles their problems results in them pursuing
generic strategies that are categorised below:

The Prospector is primarily concerned with the

identification of new market opportunities and
creates more focus on this rather than improving
internal processes.

The Analyser is characterised by sophisticated

internal information systems and detailed
investigation of options, but this is unlikely to be
followed up by the type of action undertaken by the
Prospector.

The Defender is concerned with maintaining the

current market position without exhibiting a great
 deal of initiative in developing new market
opportunities.

The Reactor simply deals with circumstances as

they arise, without any clear strategy or way
forward.

PEST and SWOT analysis

Some more tools that aid in analysing the

environment for a product include SWOT (Strengths,
Weaknesses, Opportunities, Threats) and PEST
(Political, Economic, Social, Technology) analysis.
Strategic thinking requires a holistic look at the
environment and consider different aspects that
may impact the product’s potential.

4Cs Marketing Mix

Suppose you wanted to create a marketing model

that is strong enough to “pull” customers towards
your product, instead of “pushing” them to consume
it. In 1990, Robert F Lauterborn defined a model that
examined the environment for market opportunities
known as “the 4Cs”:

1. Company: Examining the company’s internal

resources, skills, vision and strategy.
 Understanding how different opportunities could
fall within the organisation’s vision, or whether it
could steer or change it. A PO periodically scans
the market for opportunities that would make
sense for the company they are operating in to
benefit from. He/she may identify gaps in the
market that the firm can take advantage of due
to:
a. Previous product lines
b. Existing stakeholder relations
c. Cost cutting strategies

This is often how new verticals are born and how

a business evolves over time.

2. Context: the environmental context, regulations,

technology, economic, social trends. It's
important to identify whether market
opportunities are temporary trends that quickly
fade away once the next trend is in fashion. With
today’s online trending ‘buzz campaigns’, it's
easy to identify fads that come and go, and
sometimes only last a few weeks. These kinds of
opportunities may be beneficial in the short run,
if the organisation responds fast enough to the
appearance of a trend, but should be aware that
the lifecycle of the product could be relatively
short lived.
 Similarly, the economic and legal playground
could directly impact a company’s operations.
New economic trade agreements with
neighbouring countries could mean that an
opportunity for cheaper suppliers with low
import costs could give the company a
competitive cost advantage.

3. Customers: The needs, wants, behaviour,

psychology, profiles and identities of current and
potential customers. Some customers prefer
products that bring practical value over design,
while others prefer design over practicality. The
customers that use the product will give a good
indication of what to focus on because they will
vocalise what they need the most. A good PO will
inform their stakeholders about any risks or
limits that may exist in the organisation.
Sometimes, customer needs might not reflect
what's in the product roadmap and may also not
be achievable or cost-effective. It’s up to the PO
to decide if changing the product vision is
possible or worthwhile.

4. Competitors: the relative strengths and

weaknesses of competitors and trends in the
competitive environment. Entering a fierce,
competitive environment means that consumer
demand is delicate and unpredictable. On the
other hand, through innovation (and a high A2I -
 Ability to Innovate), a product’s value may shine
amongst its competitors - but what happens if
the product can be easily emulated by the
competition? That’s where the A2I comes in.
Adopting a proactive strategy so that a product
is always ‘one step ahead’ of the competition,
keeping it in a solid market position.

Marketeers refer to these elements as the 4 Cs

(previously known as the 4 Ps)

Product Life Cycle Framework

Each product (whether short, or long lived) goes

through different phases over its lifetime. The
Product life cycle defines five phases: Introduction,
Growth, Shakeout, Maturity and Decline - each one
having distinct attributes. Marketeers and strategists
use this information to tweak their product strategy
so that it best complements its current and future
phases.
1. Introduction - Characterised by low sales,
supply and demand. Typically, this occurs before
the adequate level of product awareness has
been established. Serves as a good opportunity
to test the market with different promotional
activities.
2. Growth - Product demand increases, along with
awareness and sales, towards the peak. As the
peak is reached, sales stabilise and the rate of
growth declines. The growth stage is a great
time to grab the attention of potential customers
and close the market gap.
 3. Shakeout - The growth rate continues to
decrease as more competitors enter the market
as the product loses its ‘novel’ appeal.
4. Maturity - Sales are more steady and the main
customers are made up of more loyal customers
and less “early adopters”. The product has
already tested the market and customers are
more aware of the value that it offers. Focusing
on keeping customers pleased and retaining
them is key to extending this phase.
5. Decline or Extension- The last phase where
sales decline. The product has been superseded,
driven out of the market by the competition,
costs to retain the product outweigh revenues, or
the product has simply become outdated. Some
products never really stop selling, and instead
their decline phase is extended. Retrospective
analysis during this stage can be used to enter
the market with a new product, whereas in some
cases, some products can be revived through
innovative rebranding or features.

BCG Growth Share Matrix

1970s Strategic Management promoted the use

of portfolio models to help businesses with
classifying their product’s competitive strength.
One of these tools which is still used today, is
known as the BCG growth share matrix - which
 gives insights into which investment
opportunities are likely to generate cash through
classification based on Market Growth Rate vs
Relative Market Share. These classifications
support marketing decisions in terms of pricing
or releasing new products/product features
based on their competitive reality.

The Dog - Represents a low market share in a

stable market, that is not currently making profit.
They have very little potential to be profitable in the
future since the costs of increasing its market share
are likely to outweigh the potential gains. Dogs need
increased marketing expenditure or price reductions
to divert customers away from other products.
Divesting products that are Dogs will release scarce
resources which could be put to more profitable use.

The Star - Fast-growing products that are clear

market “winners”. The objective is to maintain
market share until market growth ceases. The
product incurs relatively high marketing costs
because of the competition for new customers as
market size increases. Typically, a Star will turn into
a Cash Cow once the product matures in the market.

The Cash Cow - A mature product that has already

dominated the market (could have already been a
Star) and is reaping the benefits (revenue) from
previous promotional campaigns. Cash Cows can
quickly turn into Question Marks. If “milking the cow”
through additional product features/benefits is
feasible, the Cash Cow can turn into a Star after
becoming a Question Mark, however, if it is left to
decline and lose market share, it will turn into a Dog
instead.

The Question Mark - Products that cannot yet be

identified as one of the other classifications, may
either become a dog or a star depending whether
market share can be increased before the growth in
the market stops. The potential for Question Marks
is subject to experimentation and successful
promotion.
Diffusion of Innovation

A classic theory that is used in marketing and

entrepreneurship, this perspective can help with
predicting the market potential of a new product. It
helps develop an understanding of how fast an
innovative product can be adopted by the target
market.

The theory includes groups of potential customers

that are more likely to adopt and buy the product in
specific time periods. The rate of adoption depends
on the attitudes and behaviours of consumers, as
well as the product. However, when plotting a curve
of the percentage of individuals that respond to the
product over time, the curve tends to take the same
shape regardless of the product. Each product tends
to go through the five stages of adoption over some
period of time. The speed of adoption depends on:

1. The risk (cost of product failure or

dissatisfaction);
2. The relative advantage over other products;
3. The relative simplicity of the new product;
4. Its compatibility with previously adopted ideas,
and behaviour;
5. The extent to which its trial can be accomplished
on a small-scale basis
 6. The ease with which the central idea of the new
product can be communicated7

Naturally, some consumers are more eager to

experiment with new products or services before
anyone else. Innovators include only 2.5% of the
potential market. They enjoy trying out new things

7
Everett M. Rogers, Diffusion of Innovations (New York: Free
Press, 1983)
and sharing their experiences. Other consumers will
wait for the Innovators to take the first bite into the
product, and see what they have to say about it.

The Early Adopter group will then tend to begin

consuming the product. Early adopters are typically
part of community groups or product “influencers”
and make up 13.5% of the potential market. The
product is then adopted by the Early Majority
group, who are less likely to take risks than the
preceding groups, and will not purchase the product
before ensuring that it is successful first.

The Late Majority group represents 34% of

potential consumers. They could be less eager
about purchasing the product, but do so anyway
because of economic or financial reasons.

Laggards (about 16%) are the last group of

consumers that purchase the product, normally, this
is around the time period where the product would
already have a successor, they are comfortable with
what they already have, and are less likely to
respond to changes. This group is the hardest to
onboard.
Chapter 8

Product Roadmap

The Product Vision is broken down into goals over

time, showing the future intent of the product, in
order to achieve its vision. It enables value steering
(improving value over time) and provides a clear
direction to align stakeholders on the product’s
future strategic decisions. Essentially, a Product
Roadmap is a high level plan that can change over
time.

There are different types of product roadmap

models and Scrum does not give any
recommendation around which model to use -
choose the best fit for the product’s stakeholders.
Two models worth mentioning are the GO Product
Roadmap and the Now-Next-Later Product
Roadmap. Both convey similar messages, however
the level of detail differs between them.

The purpose of the Product Roadmap is to provide a

high level plan and direction of the product offering
at a glance.
GO (goal-oriented) Product Roadmap
8

GO Roadmap

A Goal-Oriented roadmap
includes the following for
each goal:
● A timeframe (e.g. Quarter)
● Key Feature/s
● Metrics to measure
progress towards that goal

8
"GO Product Roadmap | Roman Pichler."
https://www.romanpichler.com/tools/the-go-product-road
map/. Accessed 9 Sep. 2020.
Now-Next-Later Product Roadmap9

Now-Next-Later Product Roadmap

● Easy to understand
● Splits goals that will be pursued either
“now” “next” or “later”

9
"#now, #next, #later: Roadmaps without the Drudgery | by
...." 6 Nov. 2014,
https://medium.com/@noah_weiss/now-next-later-roadm
aps-without-the-drudgery-1cfe65656645. Accessed 9 Sep.
2020.
Product Value

Product value is based on the customer perceived

value that is developed through the benefits the
product satisfies. Value can be affected by its
nearest competing substitute, price, marketing
strategy, delivery, user experience and brand.

Similarly, value also influences product price, since

price should be set in a region between the
product’s costs and its perceived value.

Product value isn’t just determined by revenue or

profitability. There’s more than meets the eye when
it comes to investing resources to create a product
and continuously deliver value. POs often have a
predicament on which features to prioritise first -
especially when stakeholders insist that they are all
equally “urgent”. Some kind of measure needs to
exist to be able to order features in the product
backlog, and indicate their respective priority to the
Scrum Team and the stakeholders. There are
different approaches to quantifying priorities, and
you may have heard of POs using “value points”,
KPIs and ROI as quantitative measures. Certainly,
numerous indicators can contribute towards
measuring product value - as long as they remain
relevant. The absolute best measure of product
 value is and will always be based on user and
market feedback.

Value Metrics & Evidence Based

Management (EBM)

Product Owners are responsible for the decision

making of their product. They need to be able to
determine the best outcome from underlying data,
assumptions and prediction. Metrics are a
supporting backbone to the science of decision
making in most large organisations. Many business
questions are posed in the day to day operations of
an organisation - and outcomes are taken based on
a combination of things including individual
experiences and gut feelings. Data-powered
decisions are the most objective and systematic
method of supporting choices and are therefore a
handy tool for determining product value, without
being too distracted by emotions, ego or "gut
feeling".

Whilst in no means should a PO solely base their

decisions on data, they are expected to conduct
research, quantify value, measure customer
feedback, inspect trends and use metrics to improve
and grow their product.
Value Metrics
Total Cost of Ownership (TCO): This defines the
bigger picture of the total cost of the product value.
From inception, to its complete life - it includes its
past, present and future value.

Net Promoter Score (NPS) - Based on asking

customers: How likely is it that you would
recommend our company/product/service to a
friend or colleague?
The replies are rated between 0 to 10 (10 meaning I
would definitely recommend, and 0 meaning I will
never recommend) .
Customer feedback is calculated by identifying the
difference between “promoters” (i.e. respondents
that replied with a score of 9-10) and “detractors”
(i.e. respondents who gave a score from 0-6) as a
percentage. Promoters are the top customers that
are loyal to the product, whilst detractors are
customers that create traction to growth and are
likely to damage the product’s reputation. The
range of the score varies from between -100% to
100%, the higher the score, the higher the customer’s
perception of the product’s value.
 Leading vs Lagging Indicators

Leading indicator: More

future-oriented measures that can be
used to enable change. Typically
measured on a frequent basis.

Lagging indicators: Measures output

and tends to look at historical data to
derive the result. Typically measured
every month, quarter or year.
Evidence Based Management
Evidence Based Management (EBM) is a movement
that is part of evidence-based practices that are
used in many different fields. Within the remit of
business agility, EBM drives organisational initiatives
through the best evidence available.

EBM in Scrum - EBM is often mentioned within

Scrum communities since it:
(a) supports the pillars of empiricism through
continuous improvement and adaptation
(b) gives a transparent view of the value being
delivered

Take a moment to analyse the following situation. A

CEO is speaking with a product stakeholder,
suggesting that a certain feature takes priority
based on gut feeling.
Note that the stakeholder does not question the CEO
for empirical evidence to support this suggestion.

Thoughts and Predicaments

The CEO suggested shifting our focus

toward a particular feature of the
 product - but Sales have barely been
affected. What value did this feature
really bring? What data was used to
support the CEO's decision?

If the Team's velocity has only been

going higher in the previous sprints -
then why are we losing market share?

Think a little about these questions and ask yourself

whether you can think of any similar situations that
you have come across in your organisation.

Digging Deeper
If an organisation measures velocity and market
share, without measuring the delivered product
value, then the complete flow of production has a
missing link.

● Are the features being developed actually useful

to the user? Or were they given a wrong priority?

● Do more features really equate to more product

value?
● Is the team being pressured to deliver faster and
more features at the cost of quality, thus
resulting in competitors taking market share?

● Is product value delivered suffering at the cost of

boosting velocity?

Here's where product

value metrics come in

Having these metrics in place can help answer these

questions and thus influence future decisions.

Each Sprint’s investment can be inspected against

the value (financial or otherwise) that is output
through the increment and thus decide on what to
do next to maximise value. Developing more
features may not necessarily bring more value. In
fact, adding features that are not really useful to the
users, may just increase technical debt in the long
run. In this case, the features could even be reducing
the overall product value. The best measure of
impact is based on Product Value measures such as
customer satisfaction and frequent releases, not the
number of features in a release.
 A note about velocity

● Velocity is measured through a

subjective measure, and is
personalised for every team
● Velocity is not a measure of
product value. The amount of
work a team does is separate
from the value that is
experienced by a user. A team
may be delivering many features,
at a high velocity, that mean little
to nothing to the customer. In
this case, velocity is high, whilst
product value remains low.
Chapter 9

The EBM Guide

The EBM Guide10 defines four Key Value Areas

(KVAs), each having their own Key Value Metrics
(KVMs). KVMs measure both internal (measures
related to employees, product development and
release data, education, product defects, internal
costing) and external (customer usage and
satisfaction, market data) factors.

KVA 1 - Time to Market (T2M)

Purpose: Expresses the organisation’s ability to
quickly deliver new capabilities, services, or products
KVMs include:
● Release Frequency
● Cycle Time
● Lead Time
● Time to Repair
● Release Stabilisation Period
● Release Frequency

10
Evidence - Based Management
https://scrumorg-website-prod.s3.amazonaws.com/dr
upal/2019-05/EBM_Guide%20January_2019.pdf
Accessed 3 Sep. 2020
 ● Build and integration frequency
● Time to learn

Measured in: Time, duration

Used to: Identify and remove bottlenecks, introduce

automation, improve operational processes, reduce
delays and increase customer engagement through
fast response. Also, increases product
competitiveness, sales and gains competitive
advantage

KVM 2 - Current Value (CV)

Purpose: Reveals the value that the product delivers
to customers, today

KVMs include:
● Revenue per Employee
● Product Cost Ratio
● Employee Satisfaction
● Customer Satisfaction
● Customer Usage Index - A measurement of
usage, by feature. It can show whether customer
usage meets expectations.
● Investor Satisfaction

Measured in: Various units of measurement,

depending on the method used. Derived from
 marketing metrics and can range from financial
metrics, surveys, social media feedback to
qualitative customer feedback or focus groups

Used to: Analyse internal and external factors that

impact customer and employee attitude and
happiness.
Decide which product features should be retained or
dropped.

KVM 3 - Unrealised Value (UV)

Purpose: Suggests the potential future value that
could be realised if the organisation could perfectly
meet the needs of all potential customers

KVMs include:
● Market Share
● Customer or user satisfaction gap : The
difference between the customer’s desired and
current product experience.

Measured in: Various units of measurement,

depending on the method used. Derived from
marketing metrics and can range from financial
metrics to qualitative customer feedback or focus
groups

Used to: Predict potential value and future benefits.

Can be important to assess new products or feature
value. Typically, mature and declining markets will
hold more CV than UV, whilst new and growth
markets will hold more UV than CV.

In the following graphs, Product A is in the ‘Growth’

phase of the Product Life Cycle, whilst Product B is in
the ‘Decline’ phase. Product A’s UV is greater than its
CV, whilst Product B’s CV is greater than its UV.

Many investment choices can be driven by a high

UV. When CV is high and the UV is low,
investments may be redirected to other areas or
products that have more future potential for
return, or otherwise, a greater UV. The favourable
investment choice is Product A over Product B, since
Product A has more future potential of value.
 Since POs are expected to be Experimenters,
calculating the UV can help support a business case
for one investment over another.
Similarly, comparing UV with CV, helps identify gaps
of value to investigate sales trends.

KVM 4 - Ability to Innovate (A2I)

Purpose: Expresses the ability of a product
development organisation to deliver new capabilities
that might better meet customer needs

KVMs include:
● Feature Usage Index
● Innovation Rate
● Defect trends
● On-Product Index - measures the amount of
time a team spends working on the product,
the efficiency of how a team is run and their
relationship to the product’s growth
● Installed Version Index
● Technical Debt
● Production Incident Trends
● Active code branches, time spent merging code
between branches
● Time spent context-switching - Context switching
reduces focus and can delay the delivery of
value in terms of A2I and T2M also.
Measured in: Frequencies, occurrences or other
metrics that impact innovation and technical debt

Used to:
● Analyse internal and external factors that impact
customer and employee attitude and happiness.
● Increase product competitiveness, sales and gain
competitive advantage
● Determine how quickly the organisation can
pivot their product offering

The A2I can also be improved in other ways, such as

setting ‘no meeting’ days to increase focus,
increasing the cross-functionality of the team
members and team co location.

Using these KVAs and KVMs will help a PO:

1. Obtain an evidence based measure of Value
2. Identify areas to improve
3. Increase value through improved decision
making
4. Adapt, Monitor and continually improve
Product Ownership Myths

“Product strategies often fall

through and are therefore not
needed”

FALSE: Product Strategies determine the viability of a

product by analysing the unrealised customer value in
the market, understanding whether it is possible to
obtain market share through the product, how to
focus and deliver customer value and remain
competitive. A weak product strategy does fall
through, a strategy that is not kept up to date also
falls through. Failing to reflect changes into the
strategy, means that pivotal points that determine the
product success are not sufficiently thought over or
communicated, thus, this is what can actually make
the product fall through.

“Product Owners deal with internal

operations, Product Managers deal
with product strategies”

FALSE: Product Managers are not part of Scrum. The

Product Owner is responsible for both, is expected to
refine the product backlog and answer the
Developers’ questions internally. These tasks can be
delegated to the Developers, but the PO is still held
accountable. The PO is also responsible for
communicating with stakeholders to set the product
vision, strategy and roadmap. Product Management
and Product Ownership do overlap.

“A Product Owner must dictate a

clear Sprint Goal”

FALSE: The Sprint Goal is collectively communicated

and formed by the entire Scrum Team. The PO can
help make it clearer by explaining how it aligns with
the Product Vision.
 Part 3

Tactical Product
Ownership
❖ Read this section to understand the
responsibilities of the PO and how they tie into
the internal business flow, Scrum principles and
how a PO can react in practical scenarios
Chapter 10

Validation, Interaction and Feedback

Loops

Validation, Interaction and Feedback Loops are an

opportunity to:
● Learn, Inspect and Adapt about:
○ The market needs
○ The client and stakeholder needs
○ Improve the prioritisation in the Product
Backlog
○ The product

In the worst-case scenario, if the product fails, it will

fail early and inexpensively -reducing sunk costs.

Feedback Loops in Scrum:

● The Sprint is a time-boxed container full of
feedback loops (events) that give an opportunity
to learn
● Interaction with the Scrum Team and
stakeholders
● Artifacts which include validations and criteria
that give information about the expectations of
the product’s features and state
Learning checkpoints (Validation)
● Daily Stand Up
● Planning
● Review
● Retrospective
● Refinement
Empiricism and Product Ownership

● POs regularly inspect work done (including their

own) by demonstrating increments during Sprint
Reviews and testing releases in the market.
Inspection leads to adaptation when market
feedback is received. Apart from this, constant
communication with stakeholders and the Scrum
Team allows for opportunities to discuss the
product,its requirements and improvements that
can then be reflected in the Scrum artifacts (e.g.
Product Backlog Refinement).

● Growth can only stem from learning from

change and adapting towards improvement.
Product Backlog Refinement is one of the main
points of product adaptation, as well as updating
and improving the product vision, roadmap and
strategy. When product priorities shift, key
performance indicators (KPIs) for value may
reveal that customers prefer certain features
over others, which means that the perception of
value can differ from one release to another.

● Be transparent! All aspects of a good Scrum

Team depend on transparency at all levels. Open
communication between members of the Scrum
Team, key stakeholders and the clients are what
drive empiricism. Without transparency, there
can be no improvement. The PO can ensure
transparency by keeping the Product Backlog
updated and refined, communicating the vision
and the product strategy regularly, and ensuring
continuous communication with the clients,
stakeholders and Scrum Team. Remember that
Openness (speaking openly), Courage (speaking
about things that might be difficult to talk about)
and Respect (trusting what others speak about)
are core values in a Scrum environment.
 The Product Owner Scrum Event Matrix

Scrum Event Who attends? PO’s Involvement

Daily Scrum The Developers are Minimal

required, while the
rest of the Scrum
Team is optional

Sprint The Scrum Team Required for the

Planning first half

Sprint Review The Scrum Team and Required (High

any key stakeholders involvement)
such as clients, focus
groups, external
testers

Sprint The Scrum Team Required (The PO

Retrospective participates as a
peer team member
in the meeting)

1. PO and the Daily Scrum Meeting

● POs attending a Daily Scrum meeting is
optional, however participation is normally
meant for the Developers, not for the PO or
Scrum Master. Therefore, it is not considered the
 best place for the PO to answer product
questions or to interrupt them. If members of the
Team have any product related questions, it is
best to address them after the Daily Scrum.

2. PO and the Sprint Planning

● Sprint Planning serves to plan the work to be
performed in the Sprint. This plan is created by
the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of
eight hours for a one-month Sprint. What can be
achieved in this time-box may be influenced by
additional practices that are however not
prescribed by Scrum.
● Since the Sprint Planning meeting is divided into
two parts (described in more detail in Part 1), the
Product Owner is not needed in the second half
of the meeting.

3. PO and the Sprint Review

● The PO’s responsibilities in this event include
demonstrating the done features, inspecting
them, balancing user expectations, planning the
product’s future and discussing stakeholder
feedback.

● The Sprint Review exposes the work done to

the stakeholders and helps to determine
whether it meets their expectations. The PO
should be able to balance stakeholder
 expectations with the product’s development
possibilities.

● The Sprint Review is a good opportunity for

collecting user feedback - although it should not
be the only time or place to do it. Feedback
needs to be ongoing and can be asked for at
any point during the Sprint.

4. PO and the Retrospective

● The Retrospective is meant for the Scrum Team’s
inspection and adaptation. The PO is included as
a Scrum Team member who is meant to attend
and contribute to this event.
● The outcome of the Retrospective includes
actions for continuous improvement that are
added as part of the next Sprint backlog.
Product Owner Relationships

Product Owner and Scrum Master

● The Scrum Master helps the Scrum Team
understand Scrum theory, practices, rules, and
values. They can help support the Product
Owner with the best practices of the Product
Owner role, such as defining the Product Goal,
managing the Product Backlog and helping the
Developers understand Product Backlog Items.
The Scrum Master can also assist the Developers
by helping them learn techniques that improve
their effort estimations and causing the removal
of blockers that they might encounter.

● During Scrum events, the Scrum Master can be

very supportive towards the Product Owner
through the facilitation of events - allowing
everyone to contribute, while keeping events
within their timebox.

Product Owner and Developers

● The Developers are responsible for developing
the backlog items and producing them in a done
state. They are responsible for bringing a usable
increment to life. A PO will normally be
responsible for one product, having one product
backlog. There may be multiple Developers
 working on this product backlog, each having
their own sprint backlog. Developers are more
likely to produce quality when they are working
in a single Scrum Team rather than being
distributed amongst different teams. POs can
support the Developers in the best way by being
there to answer product related questions,
aligning them with the Product Vision and
strategy and managing the Product Backlog.

Product Owner and Clients/Stakeholders

● Ensuring that the Product Backlog is kept clear
and is understandable by people outside of the
Scrum Team. The PO will often communicate the
product roadmap and strategy with clients and
stakeholders. They will often ask for updates
regarding the product - Sprint Reviews are the
perfect opportunity to discuss and demonstrate
the product’s development. Feedback is obtained
from these parties and contributes towards the
product value generation.

Product Owner and Upper Management

● A crucial part of the PO’s interaction with Upper
Management is to ensure that the product vision
and strategy are aligned with the business vision.
Healthy dialogue on how the product fits into the
organisation’s objectives will help align the
organisation on different levels. Beyond this, the
Product Owner should be empowered to
independently take decisions on the product
without intervention from upper management.
Acceptance Criteria and Definition of Done

Acceptance Criteria
Each item on the Product Backlog has a description,
a priority, an estimation and value. Along with this,
items need to have one or more acceptance criteria
such as functional/non functional requirements, UX
requirements and so on. This helps the Developers
understand how the requirements can be satisfied
and how the feature can be tested.
 Example:

Note that the syntax used in this example’s

Acceptance Criteria is called Gherkin11 (Given, When,
Then). This is one of the many practices that
organisations can utilise to help standardise their
acceptance criteria.

Definition of Done

"Gherkin Syntax - Cucumber Documentation."

11

https://cucumber.io/docs/gherkin/. Accessed 4 Aug. 2020.

At the end of every Sprint, the increment needs to be
“done”, i.e. all acceptance criteria for each Product
Backlog Item are met plus, the increment meets the
organisation's Definition of Done. The Developers
always have the final say of whether the increment
is ‘done’.

The Definition of Done is created by the

development organisation (or Developers if none is
available from the development organisation).
The Definition of Done is a quality standard that
needs to be understood by everyone and is not
normally limited to a single Scrum Team. A shared,
transparent and mutually understood Definition of
Done is needed across all teams working on the
product. Any individual that is developing the
product, should be able to understand whether the
level of quality that they are producing complies
with the Definition of Done, to ensure that the work
is suitable enough to be included in a usable
increment.

Examples:
● All increments comply with legal, organisational
and compliance standards
● All increments are clearly documented
● All increments are tested through an automation
pipeline
The Definition of Done can always be improved and
refined. The Retrospective is a good time to suggest
improvements.

Chapter 11

Requirements

Requirements are a main responsibility of the PO,

who is the key contact point for clients.
Before requirements are broken down into Product
Backlog items or features, they need to be validated
for completeness, scope and clarity.

Requirements stem from different sources including

workshops, discussions (informal and formal), Sprint
Reviews, market analysis, legal constraints,
changing technologies and more.

The Product Vision, Strategy and Roadmap are

often used as a starting point and guidance for the
development of requirements for the first iterations
(normally used to develop the Minimum Viable
Product).
 During requirements gathering, the PO needs to
understand some potential challenges:12
● Problems of Scope - Requirements need to be
managed in a way that they are kept within the
product and business scope, or, where
necessary, and only if valid, the PO changes
scope and reflects that in the Product Roadmap
and Vision.
● Problems of Understanding - Requirements may
be only partially communicated, since clients
may not be completely sure of what solution
they need, or their problem domain. They may
even leave key information out. Asking key
questions, following questionnaire formats and
also educating the clients about the environment
and product help reduce this problem.
Incomplete requirements are those that cannot
eventually be tested (in that the acceptance
criteria is vague or non-existent) and do not
clearly indicate what problem or need they have
to address.
● Problems of Volatility - Some requirements are
more volatile than others. Temporary
requirements call for more attention because
they may only deliver business value in the short

12
"Issues in Requirements Elicitation - SEI Digital Library."
https://resources.sei.cmu.edu/library/asset-view.cfm?asseti
d=12553. Accessed 25 Aug. 2020.
 term. Changing requirements may also
invalidate or impact other related requirements.

In the end, requirements are sized down to be more

manageable. As a guideline, each item in the
Product Backlog:

● Is clearly understood by any Scrum Team

member - Including keeping it simple and
straightforward, without using complex jargon.
Standardisation can be used to keep formats
consistent.
● Can be tested against an acceptance criteria -
A clear acceptance criteria is shown for every
item, so that quality is set as a precedent.
● Can be completed in one Sprint - If the
Developers see that the item is too large, then
breaking it down into two or more stories will
help make the work more manageable.
● Is prioritised based on business value - Its good
to include the business value that each item is
meant to deliver in the user story itself. Some
organisations use Value Points, which is a good
indicator of value. A brief description of the value
helps to engage and align the Scrum Team.
● Clearly shows dependencies with existing
Product Backlog Items
● Clearly points out risks related to the
requirement
 ● Has enough information so that it can be given
an estimation of effort. Sometimes, the
necessary detail is not readily available, and
may require prior research or experimentation. In
that case, a different task or item can be created
with the goal of obtaining this knowledge, before
estimating the main task.
● Should be aligned with product and
organisational vision and strategy
● Needs to be kept current so updates are
continually done as priorities, dependencies,
business value, scope and requirements change

During the product life cycle, the backlog is

continually refined, as more knowledge is gained
about the product. Pichler13 advises that a healthy
product backlog needs to continually have the four
key attributes described in "DEEP".
DEEP stands for:

1. Detailed Appropriately - Top priority items will

have enough detail to be well understood, so
that development can start on these items.

2. Estimated - Each item will need to have an

estimate in order to help plan the release.

13
"Make Your Product Backlog DEEP - Roman Pichler." 8
Feb. 2010,
https://www.romanpichler.com/blog/make-the-product-ba
cklog-deep/. Accessed 14 Sep. 2020.
 Lower priority items can have less precise
estimates - these will be updated as more
knowledge is learned about the product.

3. Emergent - Items may have their priority,

description and estimates changed. They may
even become irrelevant to the product and be
removed as more is learnt about the product
requirements.

4. Prioritised - After releasing increments to the

market, users will communicate their feedback
on the business value of the product. New
priorities will emerge as increments are
inspected and more is learnt about the
product.

Nonfunctional requirements

Some requirements are not directly related to the

product, but still to be there. Non functional
requirements (or constraints) can be related to
compliance, UX, performance, transparency, privacy
and so on. They are part of a set of standards that
the product needs to meet, and are non functional.
Examples include:
 Non functional requirements examples:

Product X needs to:

● Be user friendly and easy to navigate
through
● Comply with industry standards
● Perform efficiently, even on low-end
devices

These kinds of requirements can be included in the

organisation’s Definition of Done. When it comes
down to specific tasks that are needed to carry out
work directly related to non functional requirements
(e.g. implementing a data policy for user privacy,
carrying out UX research to determine interface
layout), can be included as separate product
backlog items.

A little about User Stories

Although Scrum does not require the use of User

Stories, they are one of the most used and
recommended methods by Agile professionals to
communicate requirements.

The main purpose of User Stories are to simply keep

things concise and to the point. Requirement details
are encouraged to be communicated face to face,
so that unnecessary lengthy requirements
documents are avoided.

The story needs to always communicate three key

things:
1. The role - Who benefits from this requirement
2. The behaviour - The action that can satisfy the
need
3. The value - The reason the requirement is there,
and the benefit it brings

Also, stories should have:

● Business value description - How the business
value impacts the product or organisation
● Acceptance criteria - What criteria needs to be
met to consider the work to be accepted
A common formula for User Story components is
known as “The Three C’s”

The 3 C’s of User Stories

● CARD - User stories are meant to fit in

a ‘card’, which means that they’re
meant to be kept concise and short

● CONVERSATION - Details do not need

to be exhaustive. Communication
around User Stories is encouraged.
 ● CONFIRMATION - Acceptance Criteria
is available to confirm that the user
story delivery is successful

Although Product Backlog Items can be portrayed

using User Stories, other formats can also be used.
Diagrams, models, presentation files, videos,
spreadsheets or other information that effectively
communicates the customer’s need, can and should
be used if it helps deliver and communicate the
requirement in a better way.
Product Backlog Management

The PB is a living artifact filled with product backlog

items (PBIs) having requirements that evolve as long
as the product exists. One product necessitates its
very own PB and is always kept visible to the Scrum
Team and stakeholders.

When a product initiative starts out, the details

about how long it will take, how much it will cost and
how complex it will be, are more unknown than
known. However, as time passes by, and more
feedback loops are done, the Scrum Team gets a
better idea of :

● What is required to deliver the product features

● Potential issues become clearer, therefore risks
and effort estimates become more accurate
● Technical blockers or dependencies that were
not apparent at the start
● The quality criteria that often develops as
stakeholders test out prototypes during Sprint
Reviews
● The changes in requirements that manifest and
affect the sprint goal.
Therefore, certainty increases as more and more
information about the product and resources are
gathered. A concept that describes this theory is
called the Cone of Uncertainty, which can be used in
complex environments to predict the likelihood of
work to be done over a number of sprints.

This theory can be especially observed when Team

estimates become more accurate, the more Sprints
they complete (note, that estimates are never
perfectly accurate, and therefore there is always at
least some uncertainty).
How does this affect the Product Backlog?

The PB is a fluid artifact, it is never complete nor

exhaustive.
When there are changes in the market, the PO is
responsible for changing the PB to reflect the impact
of the change on the product’s development.

The Developers may have questions regarding the

information of the PB items, and the PO is expected
 to collaborate with them in order to ensure that the
PB items are well understood. This process is called
Product Backlog Refinement. The time spent on
refinement is as much as the Scrum Team thinks is
necessary to create enough Product Backlog items
that can be pulled in for the upcoming two or three
Sprints.

The more uncertainty there is, the more changes are

likely to happen in the PB. Shifts in priorities, feature
requirements are all reflected in the PB.
When a Sprint Planning event takes place, the
Developers determine which Product Backlog items
they will work on and complete during the Sprint. In
some cases, the Developers might not be able to
completely forecast the items that will be done at
the end of the Sprint. They can, however, start the
Sprint with the items that they feel are most likely to
be done, then continue to analyse and decompose
the remaining PB items during the Sprint. As long as
the PO makes sure that the Sprint Goal is clear, the
Developers remain responsible for the Sprint
Backlog and can decide to bring in more items from
the Product Backlog during the Sprint.

What does “Product Backlog

management” include?
PB management tasks include the following:
● Creating new PB items
● Ordering and reordering items in the PB based
on their priority (or new priority)
● Estimating the effort of the items
● Reviewing and refining the items with
stakeholders and updating their description and
details
● Identifying, reducing and eliminating
dependencies between PB items
● Breaking down larger items into smaller items
that can be developed during the duration of a
Sprint (Features/Epics, User stories/cases, tasks
etc)

The PO decides how best to order PB items based

on his/her judgement, at any time he/she thinks
is ideal. Their perception of the product’s value
helps them assess which work needs to be done first
to deliver the value that the users want. The
measures of value are not constantly set in stone -
thus the PO decides which factors best determine
product value, based on judgement and experience.
Chapter 12

Release management

A release may be done at any time (not necessarily

at the end of the Sprint) even if it is a small
increment - as long as it delivers some kind of
improvement or new outcome. The PO determines
when to release a done increment and this does not
necessarily have to be at the end of the Sprint.

Releasing an increment to the market presents an

opportunity to learn about the business assumptions
built into the product. Through collaboration with the
Scrum Team, it's possible to improve the release
process through automation of testing and
deployment (such as building continuous
improvement/continuous deployment pipelines). It's
also important for the PO to understand
impediments that occur during the release process,
how they impact the product delivery, and work with
the Scrum Team to reduce and remove them.
Release Planning

Planning the release is all about strategising and

negotiating product delivery. However, the higher
the project uncertainty, the higher the probability of
having an inaccurate release date. Before
concentrating on the method used for release
forecasting, consider the following factors before
planning a release:

Development Uncertainty - As discussed before, in

the Cone of Uncertainty, uncertainty greatly impacts
the planning process. In earlier Sprints, tools,
processes, technologies to be used and
functionalities may still have gray areas. This means
that dependencies, specialised skills, license/tooling
costs, infrastructure and architecture decisions still
need to be taken. The outcome of these decisions
will influence the entire product timeline. Initially,
focusing on a Minimum Viable Product as an early
release will also test these key decisions.

Estimation Errors - A release plan takes estimates

into consideration, but it should also take estimation
errors. Depending on the number of sprints the
team has already run in the past, data for the
estimate vs the actual amount of effort spent on a
feature, will give an indication of the error rate of
estimations. The more data available (the more
Sprints this specific Developers has finished
together), the more reliable the error rate of
estimations. Knowing that, if the error rate has
typically been +/- 20% of estimations in previous
Sprints, this buffer can also be applied to the release
date. Some tools on the market provide best and
worst case scenario predictions through Monte Carlo
simulations, Throughput and Burndown charts. While
these predictions are not meant to be accurate, they
can be useful for discussions with the team and
stakeholders.

Integration - Functionalities sometimes need to

undergo an integration process before being usable
to the market. Examples include integrating with
third party APIs or even integrating with a client’s
platform. Integration is a common dependency to
having a shippable product and can act as a
bottleneck. Examine the following questions if
integration is needed:
● Is all the integration data available to the Scrum
Team? Are endpoints, test cases, data and so on
available in early Sprints?
● Could changes to the third party platform cause
significant changes (and delays) to the delivery
of the increment?
● Is personnel availability required from the third
party to integrate successfully?
To improve predictability, analyse the possibility of
integrating the increment at the end of each Sprint.
The best and ideal product increment is unified and
includes the integrated work of each team
working on the product. Therefore, Sprint Reviews
will be used to inspect the integrated increment, not
individual increments developed separately.

Dependencies - Any dependencies that can

influence the projects:
● Other departments that may need to give
specialised input (e.g. to meet the Definition of
Done)
● Tool delivery - Such as testing devices, or any
tools required to carry out the work
● Leave/Vacation - both internally and externally
(clients, third party suppliers etc)
● PEST changes - The increment may be
influenced by environmental changes such as
policies or laws (data/industry), economic
demand, social changes (e.g. fads), technology
(new frameworks being developed that may
result in new demands)
● Changes in core Scrum team members (turnover
or new hires)

Code Freezes - Use judgement in scenarios where

some time buffer might be needed between an
increment’s last commit which has a high impact,
and the actual release date. Giving some extra time
for pipeline runs as well as manual testing, can
significantly improve the quality delivered, since
commits done towards the end of the Sprint timeline
may have unintended results or bugs that have not
yet surfaced. On the other hand, buffers also extend
your Time to Market. The quality of testing and
quality checks depend on the state of your
infrastructure and in an ideal scenario, code freeze
buffers are not needed.

Scope Changes - Do requirements change

frequently? Have they changed often in the past? If
so, then it is safe to assume that requirements will
keep changing, depending on how much leeway for
change the product vision allows.

Bottlenecks
● Are there limitations in resources and skill
expertise?
● Are key resources shared between other teams
or projects?
● Is the team or specific individuals over their
capacity limit?
● Are any of the above applicable to dependency
teams/individuals or suppliers?
● Is the decision making process slowing down?

Creating a visualisation of the process and flow can

help identify areas where bottlenecks are
happening. A method known as Value Stream
Mapping can be used to analyse the flow, identify
areas of waste or slow-down.

Fixed Constraints - The degree of flexibility of time

cost and quality differs between projects. In some
cases, constraints apply and cannot be changed:
● Quality - Some product releases are subject to
quality checks which may be required depending
on the industry. For instance F.D.A. approvals, PCI
DSS compliance, iGaming/Gambling certification
and so on. In other cases, it may simply require
the approval of a major stakeholder that is
involved with the product.

Depending on the complexity, approvals not only

eat up more time before release, but may result
in back-and-forth communication and product
rework.

● Fixed deadline - Certain products depend on

events, temporary fads or simply need to release
at a certain date to remain competitive. For
instance, changes to an eCommerce website
that promote Christmas sales need to be
planned proactively to avoid missing a pivotal
deadline.

Similarly, products may only be required

temporarily for specific events such as festivals,
elections or workshops. In these cases, missing
the deadline means that customer value drops
to zero and that the product is no longer feasible
to develop.

In both cases, the implication on release

planning is major. A reactive stance is not an
option - so release planning is even more critical
to the product’s success.
Forecasting

Different methods of forecasting can be used for

your release. Scrum does not specifically require any
single forecasting method, however one of the most
popular forecasting methods that the PO can use is
known as the Release Burndown Chart.

● Release Burndown
○ The release burndown chart illustrates the
predicted remaining effort over the remaining
number of Sprints.

○ It includes best case and worst case

predictions and can also be plotted based on
how the team’s velocity has fluctuated in the
past.

○ The actual effort is also plotted on the chart at

the end of every Sprint, so that the trends of
the difference between the predicted and
actual effort are made visible.
One caveat of the release burndown chart is that it
only considers effort that is estimated within the
product and sprint backlogs. In practice, there may
be other buffers or dependencies that may push the
release date.

For instance, a company may have a release

procedure that requires third party validation before
releasing to the market. Alternatively, releasing the
product may require integration or QA with a third
party, which in turn, requires additional time before
the product is available to the market.
As such, the general rule of thumb is to consider all
potential factors that can impact a release date.

A note about Velocity:

Measuring and tracking velocity is used to better
understand the team’s predictability. However,
velocity is not a direct output of product value, and
therefore using velocity to predict a release date
does not guarantee that the desired value will
actually be ready for release.

On the other hand, tracking the value that is

included in the “done” increments, will give a better
idea of when to expect the desired value to be ready
for release.
Releases and Risk Management

The advantage that Scrum delivers is that the PO is

able to release often to also gather customer
feedback more frequently through a short feedback
loop. However, another advantage is that small,
frequent releases help reduce the impact of a buggy
release, and also help reduce the risk of production
defects happening all at once, when releasing a
large buggy release. Having (when possible) smaller
releases, narrows down the impact to those few
features included in the release, and may even
prevent future similar incidents from happening with
increments that are still in progress.

Releasing in smaller chunks

In a scenario where a B2C software

provider is working on releasing a
loan module for their client, a major
Bank, they may decide to split the
release of a loan module by two sets
of features. First, the PO plans a
release for the features that cater for
personal loans, then they plan the
following release for the features
that serve commercial loans.

The first Sprint for personal loans is

over, and the PO sees that all the
acceptance criteria has been met.
The end users also seem happy with
the features they tried during the
Sprint Review. The PO decides to go
ahead with the release.

A few days after the personal loans

release is live, a bank operator
notices that the home loan down
payment calculation is not being
calculated correctly. When the
operator raises this issue, the Scrum
Team realises that there is a
rounding calculation error that is in
fact, affecting all downpayment
calculations. They make sure to
 inform the stakeholders about this,
and commit to release a fix within
the next 12 hours. The Scrum Team
analyse the root cause, and realise
that this issue could also be present
in the commercial loan build that is
currently being worked on. Through
learning from customer feedback, the
Scrum Team now has a better idea of
what to look out for, and will verify
that the rounding in the
downpayment calculation is
functional prior to releasing the
commercial loan features. Apart from
this, they will also add “rounding
calculation checks” in their test cases
prior to any loan module releases.

What was the outcome on product risk and impact?

By having two smaller releases of the loan module,
the risk of incorrect down payment calculations was
exposed prior to releasing the commercial loan
features. The client had confirmed during one of the
meetings, that commercial loans are given to
prestigious clients, and that the largest part of the
bank revenue comes from these types of loans. By
releasing and learning from the “less critical”
personal loan features, the Team was able to fix this
issue prior to releasing the commercial loan
features, thus avoiding rounding miscalculations on
very large amounts, that would have not only
impacted the product’s value, but also the
organisation’s and Bank’s reputation.
Release Frequency
1. Releasing too rarely
The core concept of Scrum is to work in iterations,
giving more opportunities to learn, release, handle
complexity and change. Missing those opportunities
too often goes against the principles of Scrum. So
here’s what you lose if you release too rarely:
● Competitive advantage - Your Time to Market is
impacted, you react slower to changing
consumer demands, so you give the competitors
an upper hand
● Delay in customer review - Your customers won’t
see what you’re developing for longer stretches
of time. Delaying customer feedback delays
your product improvements.
● You lose touch with the customer -
Communicating with customers without giving
tangible releases for them to see and try will
keep them ‘blind’ from what you’re building. If
you rely on screenshots and write ups to
communicate progress, they may easily imagine
something completely different than what is
actually being developed.
● The Developers will find it harder to fix defects -
Going back to change something that was
developed 3+ Sprints ago will require additional
time and might also impact items that were
developed after that.
2. Releasing too often
How do you know whether releases are being
deployed too often?
Do your end users have time to “digest” the new
features? Or does the product change so often that
they cannot get used to it?

When large eCommerce websites such as eBay

release a style change on their website, they make
sure that there is ample time for users to digest
small changes, so that a transition to a new style is
not done suddenly, but over a period of time, where
they can still use the website normally, without
having to wonder where to navigate or click.

Release frequency impacts user experience. When

Apple releases a new iPhone version, users
sometimes complain that they “just” bought the
previous one, and that they would have waited for
the latest version had they known that it would be
released so soon. Thorough market analysis
however, determines how to strike a balance
between new releases and customer value. That is,
that releases are frequent enough to provide
increased value and innovation, without diminishing
overall user experience.
Although, releasing often and early is actually the
best way to test assumptions (especially when the
PO is taking the experimenter stance), he/she
should also consider the following:

● Does the release meet the quality criteria in

order to avoid bugs or issues?
● Do the releases contain significant changes that
impact the user’s experience? Can they be
broken down into smaller changes over longer
periods of time?
● Will reduced release frequency mean that
releases will have better quality and overall
higher product value?

Releases require balance at the core, release the

minimum releasable features, release at a good
pace, ensure that the increment always meets the
definition of done.
Chapter 13

A PO's Tricky Situations - What to do, and

when to do it

Having the theoretical elements of a Product Owner

Role in place is just the baseline of what it takes to
be a PO. The reality is that they face challenges and
are often in the middle of attempting to balance the
client’s expectations without over-promising. Here
are some typical case scenarios that a PO will face,
with suggestions on how to approach them. These
cases have been taken from real life examples and
are aligned with case scenarios that have been
presented in previous Product Owner Certification
Examinations.

Unplanned work & technical debt arises

Keep in mind that this really is a problem for
everyone! The customer, the Scrum Team, the
product’s brand and the organisation’s reputation.

Technical debt slows down releases, velocity and

impacts product value, product quality. When it gets
out of hand, the Developers would end up spending
more time stabilising the system, and firefighting
 issues which affects the team’s innovation rate and
morale. Technical debt can be a result of pressure
on increased velocity, but slows down velocity in the
long run. In other words, putting pressure on
performance may lead to increased velocity at the
cost of releasing poor quality. In software
development, this expense will appear as bugs -
which will then need to be fixed (urgently in most
cases) and consequently, delay the development of
new features.

Take action to reduce or eliminate future technical

debt. One approach is to dedicate 20% of each
Sprint to improve the codebase to tackle existing
debt. The Developers can also refine and improve
the Definition of Done to minimise future technical
debt. If it’s a problem for everyone, then everyone
stands to gain. Find the root causes, invest the time
required to propose better quality checks, more
communication and take a proactive stance. Turn
the investment needed to improve into a win-win
situation.

The increment is delivered, but quality is

an issue
Best case scenario: someone in the Scrum Team
points it out prior to release
 Less ideal: Stakeholders points out quality issues
during Sprint reviews or UAT
Worst case: Stakeholders point this out after
production release (and you didn't flag it)

Key actions to take:

1. Understand whether the acceptance criteria and
definition of done include the level of expected
quality. Take steps to update them for the next
Sprint if necessary
2. Ask the Scrum Team whether the definition of
done and acceptance criteria are well
understood
3. Discuss the root cause of the quality issues with
the Scrum Team during the retrospective. Work
with them to improve the following Sprints
4. To ensure transparency, discuss the quality
issues and concerns with the stakeholders,
including the actions that will be taken to
mitigate them
5. Investigate whether the Sprint Reviews have
been helpful enough for the stakeholders to
inspect the product increment

Balancing time between client discussions,

Product Backlog refinement, meetings and
other duties is a challenge
 POs inherently need to be able to work with people,
build relationships and maintain them. This includes,
being available for the Team if they have any PB
related questions, and liaising with stakeholders to
discuss product requirements and demonstrate
available features.
Without frequent interaction with key personnel,
issues involving alignment, transparency and risk will
emerge.
Sprint reviews are a great opportunity to solidify
these bonds, since both the Team and key users will
be present.
At scale, with multiple teams working on the same
product, this can be challenging. Keeping a single
Product Owner on the product is even more
important, to reduce complexity within its network of
people. Delegating tactical product tasks to the
Developers helps with keeping the PO dedicated to
the product’s users, stakeholders and teams.

Sprint backlog items haven't been

completed at the end of the Sprint and
there is no releasable increment:
Best case scenario: someone in the Scrum Team
points it out before the end of the Sprint
Less ideal: you find out at the end of the Sprint
 A possibility here is to ask the Team to re-estimate
the effort that they think will be needed to finish the
previous work, before starting new features. Thus
the next Sprint is focused on finishing this work.
During the retrospective, the Scrum Team could
discuss why this happened, and suggest
improvements for the following Sprints. The Scrum
Master can also help the team to learn methods that
can help them predict estimates better.

A delivery needs to be expedited to

capture a market opportunity

Best case scenario: Create an understanding of the

delivery flow, understand dependencies and
bottlenecks that create delays. Work with the Team
to improve the stream of value.
Worst case scenario: Introducing overtime or hiring
more team members

Overtime rarely results in increased value delivery. In

some cases, it even backfires due to team member
burnout and takes a hit on product quality.

Hiring additional staff increases complexity. The

value added from new staff is not something that is
achieved within their first period of employment, but
 only when they are sufficiently trained and
acquainted with the Scrum Team and the product,
its features and market. Bruce Tuckman14 describes
the transition that new hires go through with the rest
of the team, known as Forming, Storming, Norming,
and Performing model. In the short-run, this can also
cause delays if key team members are needed to
dedicate time to training the new hires.

Key actions to take:

1. Never postpone the start of a new Sprint
2. Examine the root cause of the situation
3. Replan the items for the following Sprint,
negotiate new release date with the client, allow
for some buffer if possible

Stakeholders requests a major change to

a feature that is either in development or
has recently been developed

Key actions to take:

1. Always ask what triggered the change:
○ Is it an external factor that could not be
predicted?

"Developmental sequence in small groups. - APA

14

PsycNet." https://psycnet.apa.org/record/1965-12187-001.
Accessed 8 Jun. 2020.
 ○ Was this requirement communicated
incorrectly in the past?
2. Changes are very likely to happen during
complex projects and identifying improvement
areas for the response to change can be done
by measuring:
○ Cycle Time
○ Technical Debt
○ Velocity (for the same team)
○ On Product Index

The product is released, but there is little

to no customer interest, due to a low
Customer Usage Index.
Key actions to take:
1. Interview users and customers, gather their
opinions and feedback, understand what is
causing the low interest
2. Create an evidence-based hypothesis that will
reform the product in a way that meets
customer demands. Experiment with this
hypothesis to test the market response.
3. Adapt to the market needs with each release

Multiple Developers working on the same

product are finishing their planned
features, but releases are delayed when
increments are merged together.
This could mean that:

1. The definition of done is not incorporating

integration, so integration testing is not being
done during the Sprint
2. Communication and transparency between
teams needs to be improved so that the
software design includes integration
specifications
3. Tasks related to integration are not being
planned
Credits

"Manifesto for Agile Software Development."

https://agilemanifesto.org/. Accessed 10 Jun. 2020.

"The Scrum Guide - Scrum.org."

https://www.scrum.org/resources/scrum-guide. Accessed 9
Jun. 2020.

Tuckman, Bruce W (1965). "Developmental sequence in

small groups". Psychological Bulletin. 63 (6): 384–399.
doi:10.1037/h0022100. PMID 14314073. Accessed 1 Apr. 2021.

"Write the Product Vision - Martin Fowler." 5 Apr. 2017,

https://martinfowler.com/articles/lean-inception/write-pro
duct-vision.html. Accessed 2 Aug. 2020.

"How Target Figured Out A Teen Girl Was Pregnant Before

Her ...." 16 Feb. 2012,
https://www.forbes.com/sites/kashmirhill/2012/02/16/how-
target-figured-out-a-teen-girl-was-pregnant-before-her-fat
her-did/. Accessed 8 Jun. 2020.

"Competitive Strategy, by Michael E. Porter. New York: Free

...." https://www.jstor.org/stable/258056. Accessed 1 Jun.
2020.

Everett M. Rogers, Diffusion of Innovations (New York: Free

Press, 1983)
"GO Product Roadmap | Roman Pichler."
https://www.romanpichler.com/tools/the-go-product-road
map/. Accessed 9 Sep. 2020.

"#now, #next, #later: Roadmaps without the Drudgery | by

...." 6 Nov. 2014,
https://medium.com/@noah_weiss/now-next-later-roadm
aps-without-the-drudgery-1cfe65656645. Accessed 9 Sep.
2020.

Evidence - Based Management

https://scrumorg-website-prod.s3.amazonaws.com/drupal/
2019-05/EBM_Guide%20January_2019.pdf Accessed 3 Sep.
2020

"Issues in Requirements Elicitation - SEI Digital Library."

https://resources.sei.cmu.edu/library/asset-view.cfm?asseti
d=12553. Accessed 25 Aug. 2020.

"Make Your Product Backlog DEEP - Roman Pichler." 8 Feb.

2010,
https://www.romanpichler.com/blog/make-the-product-ba
cklog-deep/. Accessed 14 Sep. 2020.

"Developmental sequence in small groups. - APA PsycNet."

https://psycnet.apa.org/record/1965-12187-001. Accessed 8
Jun. 2020.
This book was done in collaboration with NBiG.

Visit our website at https://nobullinitiativeguild.com/

if you would like to learn more about Product Ownership,
Leadership, Scrum, or require personalised coaching or
training.