advanced po workshop

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: [email protected] blog: http://practical-agile.com/our-blog

mailto:[email protected]

http://practical-agile.com/our-blog


Connection before content

Respect the sticky noteOne item per sticky, use a sharpie

What questions do you have?


Parking lot

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.8

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.9


Express your preferences


The product Owner


The captain of the boat


Define the product


Focus on business results


Communicate


Define standards


Define 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


MVP

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”

[Eric Reis, 2008]


MVP

• A way to test the business assumptions: • What value does the product provide? • How much will people pay for it? • How long will it take to build the

complete solution?

MF Workshop for Product Managers at Cisco Security, March 2017

Additional MVP Questions

• What is the customers’ need? • How much will the feature cost? • What is the feature’s revenue potential? • How good is the direction of this solution? • Will our technology support this feature? • What is the minimum we should do to make

this marketable?


MVP Examples


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

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


Spiral vs. Iterative

!@#


MVP and Incremental Product Development

MVPe.g. PoC

PSP

PSPMMF

MMF

Minimum Viable Product Potentially Shippable Product Minimal Marketable Feature

Next


Come up with an MVP 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

• Confirmation


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 fit 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 notifications 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 Ep

ic

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, certifications, 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


Improve your User Stories

https://leanpub.com/50quickideas


Write Some User Stories for Your Product


Tools for generating requirement


Based on personas


Story mapping


Examine the timeline


Story Mapping Example

TimeA website for freelancers to find customers

Register Post offering get leads Close deals Get paidCreate 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:

• Focus on ROI (e.g. MoSCoW)

• Risk analysis

• Survey users to understand value (e.g Kano)

• Focus on Value and Speed (e.g WSJF, CD3)


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 haveEither dropped, or not now. Not necessarily not important


MoSCoW

Put chart from NSN PPT

0 20 40 60 80 100 1200

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


Classification 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?

I dis

like

it

It’s

OK

I’m N

eutra

l

It m

ust b

e

I Lik

e it


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 QI d

islik

e it

It’s

OK

I’m N

eutra

l

It m

ust b

e

I Lik

e it

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


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 QI d

islik

e it

It’s

OK

I’m N

eutra

l

It m

ust b

e

I Lik

e it

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 QI d

islik

e it

It’s

OK

I’m N

eutra

l

It m

ust b

e

I Lik

e it

I dislike it

It’s OK

I’m Neutral

It must be

I Like it

M Mandatory

L Linear

E Exciter

I Indifferent


Q Questionable


CD3 (Cost of Delay / Duration)

• Our default setting is to examine cost vs. schedule

• However a value vs. speed is more effective

• Check http://blackswanfarming.com/qualitative-cost-delay/

• Based on Don Reinertsen’s book Principles of Product Development Flow

http://blackswanfarming.com/qualitative-cost-delay/



https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009

https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009


Cost vs. Schedule

Feature Duration (Sprints)

Cost (100K/Sprint)

Expected Annual

RevenuePriority

A 12 1.2M ~2M 2

B 4 400K ~1M 1

C 1 100K 260K 3

D 0.5 50K ~90K 4


Cost vs. Schedule

Feature Duration (Sprints) CoD / Week CoD /

Dev-Duration Priority

A 12 40K 1.67K 4

B 4 20K 2K 2

C 1 5K 2.5K 1

D 0.5 1.7K 1.7K 3


How to practice CD3 without ‘real’ numbers?

Categorize features according to value x urgency


Qualitative CoD


Prioritize your stories on a Qualitative CoD Chart

Exercise


Estimate your stories using throw of dice

(1..6 sprints)

Exercise


Estimate Stories’ Value Each teammate:

Distribute 10 chips on stories Single Blue chip == Killer value

Exercise


Create a Qualitative CoD Flip-Chart

Exercise


Now place stories on Qualitative CoD board

Exercise


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


Patterns for Story Splitting (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 VariationsAs 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 EffortAs 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 MethodsAs 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 standardsReflects the degree of engineering skills of the team


Acceptance Criteria

• Are progressive towards a requirement being Done

• Are SMART

• Specific

• Measurable

• Attainable

• Relevant

• Timely


Acceptance Criterion

• Is a simple to follow condition

• Reflects 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 happensTHEN an expected result occurs

• Some people call it a test [And some others resent the notion of tests in requirements]

• Can promote a test-first culture


Acceptance Criteria Examples

• GIVEN login dialogWHEN user enters username=“Mickey” AND password=“Mouse”THEN user succeeds to login

• GIVEN login dialogWHEN user enters username=“Mickey” AND password=“TheMouse”THEN user fails to login

• GIVEN login dialogAND 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 Workflow_status=“bla bla" AND Processing_Time=500msAND …


Acc. Criteria for Splitting Stories

• Login with username + password

• Failed login

• Enter wrong password 3 times

• Password expired

• 3-part login

• Session timeout

Basic

Secu

rity

Adv

ance

d


Executable Specifications


Executable Specifications

• Acceptance Criteria become actual tests

• Actual tests activate code-to-be-written via fixtures

• Code gets tested as soon as it gets written

GivenWhenThen

Test Framework Fixture Actual

Code


Specification Workshops



• A practice to enhance and improve acceptance criteria

• Increases team engagement

• Increases business-domain knowledge

• Good practice to eliminate Chinese Whispers



• Performed as part of the backlog grooming

• Discuss specific examples

• Product owner contributes to understanding the business motivation

• Programmers contribute to technical edge-cases

• Testers contribute to behavioral edge-cases


Problem Space vs. Solution Space game


Defining the standards


Definition of DONE

•Terms of satisfaction of the product owner.

•Defined 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 = riskUndone = no visibility Can we

release ?


Technical Debt

Time

Work left

20

10 12 14 16 18


Come up with the DoD for your product


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

• 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

http://en.wikipedia.org/wiki/COCOMO

http://en.wikipedia.org/wiki/Wideband_Delphi

http://en.wikipedia.org/wiki/Wideband_Delphi


Educated guess (1)

•Estimate all User stories using story points (Relative estimate)

•Take several stories which you have relatively high confidence 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


What do you tell your managers?


Educated guess (Example)

•1 point = 2md — 3.07md

•Totals backlog is 500 points.

•The estimate is calculated : 2mdx500 — 3.07mdx500

•Estimate is 1000md — 1535md

Product Owner workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.Source: https://pixabay.com/en/bread-occupied-eat-snack-food-793852/

https://pixabay.com/en/bread-occupied-eat-snack-food-793852/


Reacting to Changes

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

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 finish 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 • Definition 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 paidCreate 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 3Explore 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


FeedbackCan we quote you?

Can we use your name?