Agile Product Owner Workshop Guide

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Agile  
Product Owner 
Workshop
Elad Sofer
Agile coach
co-founder @ practical-agile
twitter: @eladsof
email: elad@practical-agile.com
blog: www.thescrumster.com
Ilan Kirschenbaum
Agile coach
co-founder @ practical-agile
twitter: @_kirschi
email: ilan@practical-agile.com
blog: http://fostnope.com/

Connection before content

A-HA wall
Parking lot

!5

!6

Physical examination

Photos

Express your preferences

The
product
Owner

Deﬁne the product

Focus on business results

Communicate

Deﬁne standards

Deﬁne schedule

The captain of the boat

The painters game
• Decide who are the Artists and Designers.
• Artists - please leave the room.
• Designers - choose the messenger
• Designers are not allowed to talk or gesture with
Artists
• When using documents only simple text is allowed.
(NO speaking, drawing, or gesturing.

Round 1
8 minutes

Round 2
8 minutes

OutputInput

Concept Change
• Traditionally throws content “over the fence”– no
more!
• Takes an active role throughout the development
lifespan.
• Needs to make decisions regarding ROI every
sprint.
• The single wringable neck.

Guiding principles for the PO
• Talk directly and frequently with your customers
• Talk directly and frequently with your development
teams
• Engage the development teams in creating value
for your customers
• Maintain your product’s quality and agility – do
not let technical debt accumulate

“Would you tell me, please, which  
way I ought to go from here?”  
“That depends a good deal on where  
you want to get to,” said the Cat.  
“I don’t much care where –,” said Alice.  
“Then it doesn’t matter which way  
you go,” said the Cat
!
[Lewis Carrol – Alice in wonderland]

Create a lean canvas
for your product

The marshmallow challenge

3 simple rules
• Build the Tallest Freestanding Structure
• The Entire Marshmallow Must be on Top
• Use as Much or as Little of the Kit

The marshmallow
Challenge

Size Matters

Building the wrong product
Wave

Building the right products

User personas

User persona template

Create your own
personas exercise

User Stories

CCC
• Card
• Conversation
• Conﬁrmation

User Stories
• A recommended practice to write requirements
• Are not use cases!
• Describe requirements from the user’s POV
• Suggested formats: 
a) As a …. I would like to…. [so that….] 
b) In order to {achieve something} a {persona/user} would like to
{do something}
• “If you can’t ﬁt the story on an index card, get smaller cards!”
• Modelled for discussion, to overcome the communication gap

Investing in User Stories
• Independent
• Negotiable
• Valuable
• Estimate-able
• Short/Simple
• Testable

User Story Examples
• As a customer I want to be able to check my current balance
• As Margaret I would like to be able to see the overall
balance of the customers
• A report showing last week sales vs. current week
• In order to stay connected, as Joe I want to get all my social-
media notiﬁcations in one app
• As a network admin, I want to see a visual map of faulty
network elements, so I can analyze errors quickly

In order to work effectively
with User Stories, as a Product
Owner, I want to reserve space
for some meta data
Size Priority
Best
Before
End
Epic
This is just an example

Functional vs.  
Non Functional
• Functional - anything that the product is intended
to do to serve its purpose
• Non functional - anything else
• What is non functional tends to be elusive

Examples for  
Non-Functional Requirements
• Usability - e.g. number of clicks
• User experience - e.g. scroll acceleration
• Performance - e.g. latency and throughput
• Sizing - e.g. period of transactions to keep
• Scalability - e.g. multithreading/multiprocessing/multi-whatever-ing
• Availability e.g. 3-9s/4-9s/5-9s
• Also security, certiﬁcations, legal, and so on

Examples for  
Non-Functional Requirements
• In order to compete in the market, 3,000 sales-agents
should get a quote in less than 1 second, 24x7
• Scroll acceleration in list boxes should feel like on
iPhone
• In order to avoid data-loss, the recording module must
handle 1,000 concurrent calls
• In order to reduce hardware costs, the system must
meet 5-9s availability with 140% peak-time resources

Write Some User
Stories for Your Product

Tools for generating requirement

Based on personas

Story mapping

Examine the timeline

Story Mapping Example
Time
A website for freelancers to find customers
Register Post offering get leads Close deals Get paid
Create account
Edit account
Register
company
Delete account
Invite friends
Forgot
password
Offer service
Offer package
Discount codes
Affiliates
In-site ads
Tagging
Contact via mail
Contact form
Page visitors
Analytics
Search leads
Update site with
deal details
In-site contract
templates
Get behaviour
analytics per
customer
In-site mail
system
Publish free
content
Update offline
payment
Secure credit
card
Paypal support
Automatic
invoice
Customize
invoice

Create a story map for
your product

Why Prioritize?
• Deciding what will be developed in each iteration/
release
• Reacting to
• Requirements / needs (market)
• Actual development capability (size)
• Technology / Feasibility (risk)

How to Prioritize?
• If it is not hard, it is probably not good enough!
• Several methods exists:
• Survey users to understand value (e.g Kano)
• Focus on ROI (e.g. MoSCoW)
• Risk analysis

MoSCoW
• Introduced with early concepts of agility (DSDM,
RAD)
• Intended to quickly analyze desired scope for the
short time-boxes ahead

MoSCoW
• Must have 
Must have at least one Must
• Should have 
As important as Must, but not necessarily time critical
• Can have  
Maybe some low hanging fruit, for example
• Won’t have 
Either dropped, or not now. Not necessarily not important

Simple ROI analysis
Put chart from NSN PPT
0 20 40 60 80 100 120
0
1
2
3
4
5
6
7
8
A
BC
D
E
F
G
H
K
L
M
N
Cost
Value
Won’tMust Should Could

High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
ValueLow
High
Low
High
Risk
1
3 2
x
Risk-Driven: The objective is to start with the most important and
riskiest features – better early than late. Tackling hard, problematic
issues early is difficult and painful
Simple Risk analysis

Kano Model
• A model to understand and classify users’ needs
• Classify to Mandatory, Linear, Exciters, Neutral, Indifferent
• Mandatory - Must haves, can’t sell without them
• Linear - The more the better
• Exciters - Great if there, no problem if not
• Reverse - May satisfy some users, but dissatisfy others
• Indifferent - Most users don’t care

Classiﬁcation Example
• Mandatory - Can make phone-calls
• Linear - Memory size, Battery performance
• Exciters - Holographic display
• Reverse - Automatic Facebook check-in
• Indifferent - Built-in IDE

Kano Diagram
(Exciters)
(Linear)
(Mandatory)

Kano Survey
• For each feature ask participants two questions:
• What if the feature will be there?
• What if the feature will not be there?

Kano Survey - Example
Question
How would you feel if your
phone featured a compass?
If your phone did not have a
compass, would you like it?
Idislikeit
It’sOK
I’m
Neutral
Itmustbe
ILikeit

Analyzing a Single Requirement
Question
Q E E E L
R I I I M
R I I I M
R I I I M
R R R R Q
Idislikeit
It’sOK
I’m
Neutral
Itmustbe
ILikeit
I dislike it
It’s OK
I’m Neutral
It must be
I Like it
M Mandatory
L Linear
E Exciter
I Indifferent
R
Reverse (can
be either way)
Q Questionable

Analyzing Results - Medial
Requirement M L E I R Q Result
Requirement 1 50 35 7 8 0 0 M
Requirement 2 42 55 1 2 0 0 L
Requirement 3 20 25 45 8 2 0 E
… 12 15 11 62 0 0 I
M Mandatory
L Linear
E Exciter
I Indifferent
R
Reverse (can
be either way)
Q Questionable

Analyzing Results - Average
Question
Q E E E L
R I I I M
R I I I M
R I I I M
R R R R Q
Idislikeit
It’sOK
I’m
Neutral
Itmustbe
ILikeit
I dislike it
It’s OK
I’m Neutral
It must be
I Like it
1 2 3 4 5
1
2
3
4
5

Prioritize using the
kano model

Kano Categorization Table
Question
Q E E E L
R I I I M
R I I I M
R I I I M
R R R R Q
Idislikeit
It’sOK
I’m
Neutral
Itmustbe
ILikeit
I dislike it
It’s OK
I’m Neutral
It must be
I Like it
M Mandatory
L Linear
E Exciter
I Indifferent
R
Reverse (can
be either way)
Q Questionable

Sizing User Stories
• User stories become more granular over
time.
• Usually the stories starts as very big
items (Epics) and are split into smaller
sized items.
• Optional size - 2 stories per team per
week.

When & How ?
• Requirements grooming Refactoring
meeting
• Done by the PO with the team
• Grooming = Splitting, clarifying &
estimating

Splitting User stories
• Splitting across the data model.
• Support only a subset of attributes
• Splitting across operations
• CRUD parts of a protocol
• Splitting on results - Success and failure scenarios.
• Splitting cross-cutting concerns like Logging
Security.
• Splitting functional & non-functional requirements
• Stubbingmocking external dependencies

Choose the biggest user
story you have and split it
into smaller User stories

Acceptance Criteria

Acceptance Criteria
• The terms and conditions to be met in order to accept
a requirement as Done
• Are not the Definition of Done
• Acceptance Criteria are specific for a requirement 
Represents the contract the team accepts with each
• Definition of Done is a set of standards 
Reflects the degree of engineering skills of the
team

Acceptance Criteria
• Are progressive towards a requirement being Done
• Are SMART
• Speciﬁc
• Measurable
• Attainable
• Relevant
• Timely

Acceptance Criterion
• Is a simple to follow condition
• Reﬂects an incremental step within the requirement
• Helps the team visualize what will it look like when
it gets Done

• Is not:
• A set of instructions
• A design document
• A user-guide
• A use-case

• Recommended format 
GIVEN a pre-condition 
WHEN an action happens 
THEN an expected result occurs
• Some people call it a test 
[And some others resent the notion of tests in
requirements]
• Can promote a test-ﬁrst culture

Acceptance Criteria Examples
• GIVEN login dialog 
WHEN user enters username=“Mickey” AND password=“Mouse” 
THEN result=“Successful Login”
WHEN user enters username=“Mickey” AND password=“TheMouse” 
THEN result=“Unsuccessful Login”
AND login_type=“secure” 
WHEN username=“Mickey” AND password=“Wrong” 
WHEN submit 
WHEN submit 
THEN result=“User Blocked”

Acceptance Criteria Examples
• GIVEN order  
AND order_status=“New” 
AND number_of_items=1 
AND … 
WHEN Submit_order 
THEN Result=“Order OK” 
AND Workﬂow_status=“bla bla" 
AND Processing_Time=500ms 
AND …

Acc. Criteria for Splitting Stories
• Login with username + password
• Failed login
• Enter wrong password 3 times
• Password expired
• 3-part login
• Session timeout
BasicSecurityAdvanced

Executable
Speciﬁcations

Executable Speciﬁcations
• Acceptance Criteria become actual tests
• Actual tests activate code-to-be-written via ﬁxtures
• Code gets tested as soon as it gets written
Given 
When 
Then
Test
Framework
Fixture
Actual 
Code

Speciﬁcation
Workshops

Speciﬁcation Workshops
• A practice to enhance and improve acceptance
criteria
• Increases team engagement
• Increases business-domain knowledge
• Good practice to eliminate Chinese Whispers

Speciﬁcation Workshops
• Performed as part of the backlog grooming
• Discuss speciﬁc examples
• Product owner contributes to understanding the
business motivation
• Programmers contribute to technical edge-cases
• Testers contribute to behavioral edge-cases

Write acceptance criteria
for your top priority items

MVP
• MVP = Minimum Viable Product
• A way to test the business assumptions.
• Does the product provide value?
• Will people pay for it?
• How long will it take to build the
complete solution?

MVP Examples

Come up with an MVP
for your product

Deﬁning the standards

Deﬁnition of DONE
• Terms of satisfaction of the product owner.
• Deﬁned by the PO with the team.
• Example:
• Design, code, tested, installer ready,
documented, less than 10 known bugs.
• Identical for all items in the backlog.

Beware of undone work
Undone Undone Undone Undone
Stabilization  
sprint(s)
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Undone = risk
Undone = no visibility Can we
release ?

Technical Debt
Time
Work
left
20
10 12 14 16 18

So…
How
much will
this MVP
cost?

S U I C I D EPlease consider it

There is no known way to accurately
calculate the cost of a s/w project

Estimating cost (in advance)
• Once you have estimated the scope you may try
and put a price tag on it
• You have several methods:
• Use past data to estimate progress
• Works better with same team, same
technology and same product
• Run a single cycle to try and get a rough
estimate on progress
• Educated guess

Educated guess (1)
• Estimate all User stories using story points
(Relative estimate)
• Take several stories which you have
relatively high conﬁdence in.
• Without looking at the points, estimate
them in time units.
• Calculate average for a story point (A
range)

Educated guess (2)
• Now you have the time effort estimate
(range) for a single point.
• Multiply the total points in your
backlog with the “time per point”
parameter.
• Send the price quote to your manager.
• Pray.

Educated guess (Example)
• Now you have the time effort estimate
(range) for a single point.
• Multiply the total points in your
backlog with the “time per point”
parameter.
• Send the price quote to your manager.
• Pray.

• We need to estimate cost for 500 points.
• We choose 3 stories - A(8),B(13) & C(5)
• A is estimated at 20 MD = 2.5 md/p
• B is estimated at 40 MD => 3.07md/p
• C is estimated at 10 MD => 2 md/p

• 1 point = 2md — 3.07md
• Totals backlog is 500 points.
• The estimate is calculated :  
2mdx500 — 3.07mdx500
• Estimate is 1000md — 1535md

Reacting to Changes

Tracking progress
• To guess progress, you need the following
combination:
• Average completion rate (aka Velocity,
yesterday’s weather)
• Total remaining work
• Deﬁnition of Done being followed
• You can ask how much time left?
• Total unﬁnished / avg. Velocity
• Time and cost derive from the previous one

Visualising the data
• Visualizing the data should provide answers stakeholders are
looking for:
• Content status – What is complete and what is not
• Progress status –
• How are we progressing according to original estimates?
• When do we expect to be done?
• When will feature X be ready for review?

Burndown chart analysis
• Just by looking at the ProductRelease burndown,
we can “smell” issues
• Combining the standard BD chart with other, more
advanced data can really teach us a lot about our
product

0
35
70
105
140
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Effort left
Total stories
Aha!
May apear that
there is no
progress

Earned Value Management (EVM)
• A simple way to visualize
• Scope
• Schedule
• Cost

EVM
• Scope
• Accumulated value of done things
• If estimating value is hard, use relative value
• If estimating relative value is hard, try using size 
(it may be better than no number at all)
• Alternatively use number of known stories
• Schedule
• Plotting iterations (or other cadence) on the X-axis

EVM
• Cost
• If obtaining cost is hard, use other abstract
representation
• Team/s allocation is usually simple enough
• Avoid using cumulative micro data (e.g.
timesheet reports)

We would rather be wrong than uncertain
Dan North

Earned Value Monitoring
0
23
45
68
90
1 2 3 4 5 6 7 8 9 10 11
Earned Value
Budget
Typical ’S’ Curve

’S’ Curve
• Explore 
- maximize discovery
• Stabilize 
- maximize variance
• Commoditize 
- maximize efﬁciency 
…and a good sign to move to the next thing

EVM - Exercise
0
25
50
75
100
1 2 3 4 5 6 7 8 9 101112131415
Earned Value
Budget
Budget Forecast

Decide what to do
now

Long term"
• Sometimes the org market requires you to plan ahead
several releases.
• Ways to do that is:
• Story mapping (Focuses on scope)
• Velocity based (Focused on time)
• EVM (Focuses on budget)
• Don’t! Focus on continuous delivery of business goals

Story Mapping Revisited
Time
A website for freelancers to find customers
Register Post offering get leads Close deals Get paid
Create account
Edit account
Register
company
Delete account
Invite friends
Forgot
password
Offer service
Offer package
Discount codes
Affiliates
In-site ads
Tagging
Contact via mail
Contact form
Page visitors
Analytics
Search leads
Update site with
deal details
In-site contract
templates
Get behaviour
analytics per
customer
In-site mail
system
Publish free
content
Update offline
payment
Secure credit
card
Paypal support
Automatic
invoice
Customize
invoice
Release 1 Release 2 Release 3

BDC Revisited
0
25
50
75
100
R1 R2 R3 R4 R5
Effort left
Added Effort

EVM & Forecasting
0
25
50
75
100
1 2 3 4 5 6 7 8 9 101112131415
Earned Value
Budget
Budget Forecast
R1
R2
R4
R3

Dont! Focus on
business goals. How?

Impact mapping

Impact mapping
Business
Goal
Who can help
achieve the
goal
How can
they help
What can i
do to
encourage them
to do it?
Who
Who
How
How
How
What
What
What
User
Story
How could i do it?
User
Story
User
Story

We want 1000
more freelancers
registered
Registered
freelancers
Unregistered
freelancers
Other site
owners
Friends
Family
Invite friends
Posting about
the site
Give bonus for invites
As a freelancer i would
like to get 1 month free
when i invite a friend
As site admin i would
like to freelancers that
have more than 5
invited promoted on
search results

Choose a goal (You can use the
“key metrics” in your lean canvas)  
 
And Create an impact map

Questions?
Parking lot

Feedback 
Can we quote you?
Can we use your name?

Agile Product Owner Workshop Guide

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Agile Product Owner Workshop Guide

Similaire à Agile Product Owner Workshop Guide (20)

Plus de Elad Sofer

Plus de Elad Sofer (13)

Dernier

Dernier (20)

Agile Product Owner Workshop Guide