Practical-Agile Product owner workshop

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

Agile Product Owner

WorkshopElad Sofer

Agile coach co-founder @ practical-agile

twitter: @eladsof email: [email protected]

blog: www.thescrumster.com

Ilan Kirschenbaum Agile coach

co-founder @ practical-agile twitter: @_kirschi

email: [email protected] blog: http://fostnope.com/

mailto:[email protected]

http://www.thescrumster.com

mailto:[email protected]

http://fostnope.com/


Connection before content



A-HA wall

Parking lot

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

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


Physical examination


Photos




Express your preferences


The product Owner


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


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

• 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


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:

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


Simple ROI analysis

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



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 • Stubbing\mocking 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 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 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-first culture


Acceptance Criteria Examples

• GIVEN login dialogWHEN user enters username=“Mickey” AND password=“Mouse” THEN result=“Successful Login”

• GIVEN login dialogWHEN user enters username=“Mickey” AND password=“TheMouse” THEN result=“Unsuccessful Login”

• GIVEN login dialogAND 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 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


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


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


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

•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 • Definition of Done being followed

• You can ask how much time left? • Total unfinished / 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 Product\Release 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 leftTotal 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 ValueBudget

Typical ’S’ Curve


’S’ Curve

• Explore - maximize discovery

• Stabilize - maximize variance

• Commoditize - maximize efficiency …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 ValueBudgetBudget 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 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 3


BDC Revisited

0

25

50

75

100

R1 R2 R3 R4 R5

Effort leftAdded Effort


EVM & Forecasting

0

25

50

75

100

1 2 3 4 5 6 7 8 9 101112131415

Earned ValueBudgetBudget 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?

Practical-Agile Product owner workshop

Text of Practical-Agile Product owner workshop

Agile Team Roles Product Owner & ScrumMaster · Agile Team Roles Product Owner & ScrumMaster ... prioritizes Product Backlog Sprint 1 to 4 weeks Team (BA, QA, ... management on agile

Agile Practical Tactics

Practical Agile QA

Product Owner Team - Agile Day Atlanta 2015

Practical Implementation of Agile Methodologies

INTRODUCTION TO INTERNATIONAL AGILE PRODUCT OWNER FOUNDATION - SCRUM … · 2019-03-14 · 01 INTRODUCTION TO "INTERNATIONAL AGILE PRODUCT OWNER FOUNDATION" 4 02 CREATE PRODUCT VISION

Practical Agile Data Warehousing Final

Product Owner Challenge Agile in the City Birmingham 2017

Product Owner Challenge 3.0 (Agile Cambridge 2016)

10 Practical steps for Agile transformation · 10 Practical steps for Agile transformation Nikola Bogdanov, Agile Coach 08/01/2018 Today only: 5 bonus!

BCS Certificate in Agile Product Owner · An Agile Scrum Product Owner certificate ensures that a candidate can successfully lead Agile Scrum projects in the context of an overall

Agile at OPM: the USAJOBS Product Owner Perspective

Product Owner in an Agile Extremely Scaled · Product Owner in an Agile Extremely Scaled World Agilia 2016 - Olomouc ... • Agile methodologies are abandoned (It doesn’t work!)

Agile product owner training online

Agile @ OPM: the USAJOBS Product Owner Perspective

A Practical Guide to Scaling Agile

Certified Agile Process Owner (CAPO) Reference Card

Agile ux practical design without wireframes

The Practical Adoption of Agile Methodologies

Agile development in practical world

EXIN Agile Scrum Product Owner · EXIN Agile Scrum Product Owner is a certification that looks to confirm both skills and knowledge of ... Guide of the EXIN Agile Scrum Foundation

Product owner roles and responsibilities in agile scrum methodologies

The Agile Product Owner: Beyond the Books and Classrooms

Practical Usage of Agile & Agile Case Studies

Planning Your Agile Testing: A Practical Guide

Table des matières - Settis2 AGILE ET SCRUM Formation Agile : Product Owner Durée : 2 jours Public : Toute personne devant jouer le rôle de Product Owner dans un projet agile Scrum

Agile Product Owner

What is an Agile Product Owner

A Practical Guide to Agile BPM Implementationmercatorg.com/.../2015/04/TMG-Practical-Guide-to-Agile-BPM-M… · Prologue The Practical Guide to Agile BPM, and Business Process Management

Practical Caravan - Owner Satisfaction Awards 2014