Cover

Product Owner
Manual

ambuzzador Agile Business Coaches +43 1 522 40 71

speakingagilefuture@ambuzzador.com

1
 PRODUCT OWNER MANUAL

This manual
is intended for:

- Product Owners who want to keep track of their

functions and agenda in the Scrum Process

- anyone who wants to get familiar with SCRUM,

especially with the role Product Owner

1
 PRODUCT OWNER MANUAL

Table of Contents

Scrum Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
List of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
What does a Product Owner do?. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

The Product Owner’s Role in

Product Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
User Story (Epic). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Product Backlog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Release Forecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Sprint Planning 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Backlog Refinement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Estimation Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2
 PRODUCT OWNER MANUAL

Scrum Overview

 SCRUM FLOW

VISION

Product Owner (PO)

1 2 3 4 5
PRODUCT BACKLOG IMPEDIMENT RELEASE
• prioritise (ROI) BACKLOG FORECAST
• estimate
Strategy

BACKLOG
REFINEMENT
SPRINT PLANNING 1 SPRINT PLANNING 2
Analysis Design

Commitment SM PO Dev Team

WHAT? HOW?
35‘
Tactical
SM PO Dev Team Manager Customer SM Dev Team
Work
60‘ / Week / Sprint 60‘ / Week / Sprint Work
Work
plan – do – check – act

DAILY SCRUM
ITERATIONS = SPRINTS TO DO WIP FEEDB DONE

RETROSPECTIVE SPRINT REVIEW

Feedback Feedback SM Dev Team
15‘
PROCESS PRODUCT
Approval

SM PO Dev Team SM PO Dev Team Customer User

90‘ 90‘

Scrum Master (SM) Manager Development Team (Dev Team)

Product Owner (PO) User Customer

3
 PRODUCT OWNER MANUAL

Scrum Overview

 SCRUM ROLE OVERVIEW

User

Development Team
(Dev Team)

Customer Product Owner Scrum Master Manager

(PO) (SM)

 SCRUM RITUALS  SCRUM ARTEFACTS

• Sprint Planning 1 (SP1) – What? • Product Backlog

• Sprint Planning 2 (SP2) – How? • Release Forecast
• Daily Scrum • Task Board (Sprint Backlog)
• Review – Product • Product Increment
• Retrospective (Retro) – Process • Definition of Done
• Backlog Refinement • User Story / Epic
• Product Vision
• Impediment Backlog

4
 PRODUCT OWNER MANUAL

List of Terms

AGILE AGILE VALUES:

Agile is an iterative philosophy that These are the 5 Values

allows the increment building of a Agile is based on:
product. One of its main benefits
is the ability to continuously adapt - Respect
and change and to only supply - Commitment
relevant products to the market. - Focus
It is based on the Agile Manifesto, - Courage
Agile Principles and Agile Values. - Openness

SCRUM SCRUM TEAM

The term “Scrum” (stems from includes the Development Team,

Rugby) was used by Nonaka and Product Owner and Scrum Master.
Takeuchi’s 1986 article “The New
New Product Development Game”
to describe effective team work. DEVELOPMENT TEAM
For the use in Project manage-
is responsible for the delivery and
ment there are certain rules and
the product quality. The Dev Team
roles in order to work efficiently
is self-organised and deliveres
together as a team.
the product.

5
 PRODUCT OWNER MANUAL

What does a
Product Owner do?
The Product Owner owns the Product Backlog. You, as a Product
Owner, decide what elements it contains and in what order they are
prioritised.

 MAIN RESPONSIBILITIES OF THE PRODUCT OWNER

• Maximising the Return on Investment for your product

 HAS EXPERTISE IN …

• Business Case
• Market
• Company Vision and Roadmap
• Customers and (end) Users
• Pitching and Listening

 HOSTS THESE MEETINGS  ARTEFACTS OF THE PRODUCT OWNER

• Sprint Planning 1 • Product Vision

• Backlog Refinement • Product Backlog
• Sprint Review • User Story / Epic
• Participates in the Sprint • Release Forecast
Retrospective

6
 PRODUCT OWNER MANUAL

ARTEFACT

Product Vision

 GOAL OF PRODUCT VISION

The Product Vision motivates the team and provides direction for the
development of the product.

 PRODUCT VISION

• Keep it short and simple. 1-2 sentences should suffice.

A graphic visualisation would be great too.
• It should be emotionally appealing as well as inspiring and answer
the most important questions:
• What?
• Why?
• For whom?
• When?
• How will we know that we have reached it?
• Make sure to communicate the Product Vision continuously:
• in team meetings
• in all stakeholder communication
• when meeting colleagues on your coffee breaks

Develop a digital product canvas to help

Vision Statement teams create great products

Target group Needs Product Value

Users: Product Have an effective tool Tablet app Open up a new
managers and for creating UX-rich revenue stream
Looks like a physical
product owners products
canvas; intuitive in Develop our brands
Customers: Mid-size Leverage the existing use and reputation
to large enterprises investment: minimise
Provides guidance
the cost of acquiring a
and templates
new tool

7
 PRODUCT OWNER MANUAL

ARTEFACT

User Story (Epic)

 GOAL OF USER STORY

Like every artefact, the User Story should be continuously challenged,

re-written and filled with more details as it moves up in the Product
Backlog. User Stories translate User’s pain points and benefits into
everyday language.

 USER STORY

• You are responsible for the user stories. You should create them
together with the Dev Team.
• User stories are written from the perspective of a persona or real
customer / end user. If the benefit is not clear from reading the user
story, it is not a user story.
• User stories are perfect for talking to stakeholders as well as
for interdisciplinary teams since they focus on the customer’s
perspective. This way, the Dev Team doesn’t end up in technical
discussions and the focus lies on the end product.
• Top-priority user stories have acceptance criteria, requirements,
constraints, (automated) user tests, dependencies and all other
information that the Dev Team may need in Sprint Planning 1.
• Big user stories are called epics. Epics should never appear in Sprint
Planning 1. Instead, they should have been split into user stories
many weeks prior to that meeting.

Story ID: Story Title:

User Story: Importance:
As a: <role>
I want: <goal>
Estimate:
So that: <reason>

Acceptance Criteria: Type:

I know I am done when: □ Search
□ Work-flow
□ Manage Data
□ Payment
□ Report /View

8
 PRODUCT OWNER MANUAL

ARTEFACT

Product Backlog

 GOAL OF PRODUCT BACKLOG

Like every artefact, the Product Backlog should be continuously

challenged and re-prioritised. It transparently shows the work of the
Dev Team.

 PRODUCT BACKLOG

• All user stories are prioritised – starting with the next most important
user story (according to ROI). The priority changes continuously and is
your responsibility.
• All user stories have been (roughly) estimated by the Dev Team or will
be estimated in the next Backlog Refinement.
• The Product Backlog is organised like a pyramid. The closer a user
story comes to the top, the more details should be known about it at
this stage. The further away it is from development, the less detailed
the story should be (= Epic). There is no need to discuss details yet, if
there’s enough time for the customers to change their mind.
• You can use a tangible product backlog with sticky notes on the wall,
Microsoft Excel or digital tools like JIRA. Whatever works best for you
and your environment. However, the Product Backlog should be easily
accessed by all team members at any given time.

Product Backlog

high
next 1-3 Sprints

Sprints 4-6 Level of Priority

Sprints 7+

low

9
 PRODUCT OWNER MANUAL

ARTEFACT

Release Forecast

 GOAL OF RELEASE FORECAST

The Release Forecast shows at what point in time which features will
most probably be delivered.

 RELEASE FORECAST

• The Release Forecast places the Product Backlog along a timeline

and uses the Dev Team’s velocity to forecast at what point which
user stories will be done. Thus, more realistic deadlines can be
communicated towards all stakeholders.
• The Dev Team’s velocity is calculated based on previous sprints.
You can either use the sum of all story points or the amount of user
stories finished per sprint. Your Dev Team’s past velocity is most likely
to be its future velocity. Since you have a Scrum Master by your side
who actively increases the Dev Team’s productivity, you can expect
the velocity to increase steadily.
• Since the product’s scope is continuously adapted, the Release
Forecast should be used to inform your stakeholders and re-prioritise
the user stories together with them.

10
 PRODUCT OWNER MANUAL

Sprint Planning 1

 GOAL OF SPRINT PLANNING 1

The team commits to what it will deliver by the end of the sprint.

 FRAME OF SPRINT PLANNING 1

• max. 1 hour / week of sprint

• marks the official start of a sprint
• participants: PO, Dev Team, SM. If possible: all necessary
stakeholders of the project / user stories that will be discussed

 AGENDA OF SPRINT PLANNING 1

• You explain the overall project vision, goal for the sprint and start by
describing the top-priority user story.
• The Dev Team challenges, discusses and analyses the user story
to better understand it: acceptance criteria, user and customer
perspective, requirements, constraints, user tests to be done,
dependencies, other quality measures etc. Once the final product
increment of the user story is clear and all questions have been
answered, the team commits to delivering it by the end of the sprint.
• This process continues with each user story until the team has
enough work for the next sprint. Then the meeting ends.

 DOs  DON’Ts

++ You are the host of this meeting.
Invite stakeholders, customers,
end users, other product own-
ers etc. Don’t forget – this is a
product marketing opportunity.
++ Make sure that each story has
been discussed and estimated
prior to the meeting.
–– Don’t bring user stories to the
Sprint Planning 1 that the Dev
Team has never seen before.
You should have created them
before SP1 together with the
Dev Team.
–– Don’t push the team to
committing to something that it
won’t be able to keep.

11
 PRODUCT OWNER MANUAL

Backlog Refinement

 GOAL OF BACKLOG REFINEMENT

The team has a strategic overview of the Product Backlog and gives
input / feedback.

 FRAME OF BACKLOG REFINEMENT

• max. 30 minutes each week

• participants: PO, Dev Team, SM

 AGENDA OF BACKLOG REFINEMENT

• You give an overview of the product backlog and user stories that you
would like to have estimated on the day.
• The Dev Team challenges, discusses and analyses the user stories
to better understand them. They then (re)estimate the user stories
based on the new information by either using Magic Estimation
(large number of user stories) or Planning Poker (small number of
user stories).
• Make sure that the user stories with top priority for the next sprint
are small enough to be finished within a sprint.
• Be sure to update your Product Backlog once the meeting is over and
make appointments with stakeholders to clarify all questions that
were brought up by the Dev Team.

 DOs  DON’Ts

++ you are the host of this meeting –– don’t use up too much time of
++ Choose the user stories the the meeting to discuss user
Dev Team should estimate stories that won’t appear within
in advance. Depending the next 3 sprints
on the number, you should
either use Magic Estimation or
Planning Poker.

12
 PRODUCT OWNER MANUAL

Estimation Meeting

 GOAL OF ESTIMATION MEETING

The Dev Team gets the necessary knowledge about the User Stories
in the Product Backlog and a common picture of the product.

 FRAME OF ESTIMATION MEETING

• max. 35 minutes each week

• takes places before the Sprint Review
• participants: PO, Dev Team, SM, Manager, User, Customer

 AGENDA

• you present the prioritised Product Backlog items that need to be

estimated based on funcionality (not effort!) by the Dev Team
• the Team uses for example Planning Poker Cards to estimate the size
of the product backlog items
• User Stories that are too large can be broken down into smaller ones
• identify Backlog items which need to be clarified by you by the next
Estimation Meeting

 DOs  DON’Ts

++ only the Dev Team estimates –– don’t let the Dev Team estimate
the product backlog items effort instead of funcionality
++ you need to be present to help –– don’t estimate Stories during
decide how a User Story can be the Spring Planning 1 Meeting
broken down into smaller pieces
++ you have prioritised the Product
Backlog in advance of the
estimation meeting

13
 PRODUCT OWNER MANUAL

Sprint Review

 GOAL OF SPRINT REVIEW

All stakeholders inspect the delivered product increments

and give feedback.

 FRAME OF SPRINT REVIEW

• max. 1 hour / week of sprint

• participants: PO, Dev Team, SM. If possible: all necessary
stakeholders of the project / product increment / user stories that
will be discussed

 AGENDA OF SPRINT REVIEW

• You explain the overall vision and committed goal for the past sprint.
• The Dev Team starts by demonstrating the delivery of the top-priority
user story. Stakeholders (and team members) give feedback, which
you might want to make a note of and later add to the product
backlog. This process continues until the last user story has been
demonstrated.
• You sum up the received feedback and end the meeting with an
overview of the upcoming top-priority user stories that will be
delivered in the upcoming sprints. You can also show the release
forecast.

 DOs  DON’Ts

++ you are the host of the meeting
++ make sure to ask the customers
and end users many questions
about their use of and hopes for
the product
–– don’t use this meeting to
accept the finished user
stories as this should happen
continuously throughout the
sprint

14
 Contact us

+43 1 522 40 71
speakingagilefuture@ambuzzador.com
www.ambuzzador.com

15