Advanced Po workshop November 2015

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Agile  
Product Owner 
Workshop
Ilan Kirschenbaum
Agile coach
co-founder @ practical-agile
twitter: @kirschi_
email: ilan@practical-agile.com
blog: http://practical-agile.com/our-blog

Connection before content

A-HA wall
Parking lot

Parking lot

6

7

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

Round 3
8 minutes

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

The Product Owner a-la Scrum Guide
• Responsible for maximizing the value of the
product and the work of the Development Team.
• How this is done may vary widely across
organizations, Scrum Teams, and individuals.
• The Product Owner is the sole person responsible
for managing the Product Backlog.

• Product Backlog management includes
• Clearly expressing Product Backlog items
• Ordering the items in the Product Backlog to best achieve goals
and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear
to all, and shows what the Scrum Team will work on next
• Ensuring the Development Team understands items in the Product
Backlog to the level needed

• The Product Owner may do the above work, or have
the Development Team do it.
• However, the Product Owner remains accountable.
• The Product Owner is one person, not a committee
• The Product Owner may represent the desires of a
committee in the Product Backlog, but those
wanting to change a Product Backlog item’s
priority must address the Product Owner.

• For the Product Owner to succeed, the entire
organization must respect his or her decisions.
• The Product Owner’s decisions are visible in the
content and ordering of the Product Backlog.
• No one is allowed to tell the Development Team to
work from a different set of requirements
• the Development Team isn’t allowed to act on what
anyone else says

“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 Stories
• Vague terms
• Identify vague terms in your story and refine
them as different user stories
• Conjunctions
• Split around AND, OR, WHEN, IF
• Acceptance Criteria
• Each criteria can go to its own story
• Workflow Steps
• Each step in the flow can be its own story

Pa#erns for Story Spli1ng (cont.)
Operations (e.g. CRUD)
As a user, I can manage my account.
...I can sign up for an account.
...I can edit my account settings.
...I can cancel my account.
Business Rule Variations
As a user, I can search for flights with
flexible dates.
...as “n days between x and y.”
...as “a weekend in December.”
...as “± n days of x and y
Major Effort
As a user, I can pay for my flight with
VISA, MasterCard, Diners Club, or
American Express.
...I can pay with one credit card type  
(of VISA, MC, DC, AMEX).
...I can pay with all four credit card types  
(VISA, MC, DC, AMEX).
Data Entry Methods
As a user, I can search for flights between
two destinations.
...using simple date input.
...with a fancy calendar UI.
… …

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 user succeeds to login
WHEN user enters username=“Mickey” AND password=“TheMouse” 
THEN user fails to login
AND login_type=“secure” 
WHEN username=“Mickey” AND password=“Wrong” 
WHEN submit 
WHEN submit 
THEN user is 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

https://dl.dropboxusercontent.com/u/27532820/original_screencast.html

Spiral vs. Iterative
!@#

Customer Collaboration 
over Contract Negotiation
MVP 
e.g. PoC
PSP
PSPMMF
MMF
Minimum Viable Product
Potentially Shippable Product
Minimal Marketable Feature
Next

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

EsDmaDng cost (in advance)
• Once you have estimated the scope you may try
and put a price tag on it
• Since information is missing we can:
• Use past data (experience) - Consult the experts
• Educated Guess => Guesstimate
• Use semi formal models (COCOMO , Wideband
Delphi,…)
• Run a single cycle and roughly measure progress

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)
• 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

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

Reacting to Changes

http://artparty4u.wix.com/xtremeaverage/apps/blog/wtc-ceo-andrew-messick-on-ironman-swim :‫מקור‬

Progress
• Think WAZE
• Progress =  
(Remaining effort) / (Total Effort)

Three Broad Strategies
• What can we complete in X time?
• How long do we need to complete Y?
• Can we ﬁnish Y within X time?

Tracking progress
• To guess progress, you need to know:
• Average completion rate  
(aka Velocity, yesterday’s weather)
• Total known remaining work
• Deﬁnition of Done being followed

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

Burndown
• A simple way to visualize
• Done Scope Progress
• Schedule
• (Optional: Budget Consumption)

Burndown
• Scope
• Total remaining scope - Accumulated done
things (i.e. Done-Done stories)
• Schedule
• Plotting iterations on the X-axis

Release Turndown Chart
Linear Regression
Remaining work each
Sprint
Sprints

Burndown Data

Burndown with Scope Trend
Trend of scope
burndown
Trend of scope
additions
Intersection
= Forecast end
sprint

Long Term Planning
• Story mapping (By Scope)
• Velocity based (By Time)
• 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
Explore Stabilize Stabilize

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?

Advanced Po workshop November 2015

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Advanced Po workshop November 2015

Similar to Advanced Po workshop November 2015 (20)

More from Ilan Kirschenbaum

More from Ilan Kirschenbaum (15)

Recently uploaded

Recently uploaded (20)

Advanced Po workshop November 2015