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

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

Building the right products

User personas

User persona template

Create your own personas exercise

User Stories

• 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

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

Won’tMust Should Could

High Risk Low Value

High Risk High Value

Low Risk Low Value

Low Risk High Value

ValueLow

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?

It’s

I’m N

Analyzing a Single Requirement

Question

Q E E E L

R I I I M

R R R R QI d

It’s

I’m N

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

It’s

I’m N

I dislike it

It’s OK

I’m Neutral

It must be

I Like it

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

It’s

I’m N

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

• 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

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

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

Work left

10 12 14 16 18

So… How

much will this MVP

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Effort leftTotal stories

May apear that there is no progress

Earned Value Management (EVM)

• A simple way to visualize

• Scope

• Schedule

• Cost

• 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

• 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

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

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

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

R1 R2 R3 R4 R5

Effort leftAdded Effort

EVM & Forecasting

1 2 3 4 5 6 7 8 9 101112131415

Earned ValueBudgetBudget Forecast

Dont! Focus on business goals. How?

Impact mapping

Business Goal

Who can help achieve the

How can they help

What can i do to

encourage them to do it?

User Story

How could i do it?

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

Technology

Transcript of Practical-Agile Product owner workshop

Agile Service Management Where ITIL Meets Agile Service Management... · Agile Service Management Where ITIL ® Meets Agile. #askitsm ... . ITIL ... Certified Agile Process Owner

Agile Product Owner in Wonderland!

Practical Usage of Agile & Agile Case Studies

Agile product owner training online

How Product Owner Teams Scale Agile Methods to Large ...

Product Owner Challenge 3.0 (Agile Cambridge 2016)

Agile Practical Tactics

A Practical Agile Approach For A Non Agile Environment

Practical Implementation of Agile Methodologies

EXIN Agile Scrum Product Owner - Amazon S3 · 2018-09-30 · Guia de Preparação: EXIN Agile Scrum Product Owner (ASPO.PR) 4 1. Visão geral EXIN Agile Scrum Product Owner [ASPO.PR]

Practical Boat Owner - October 2014 UK

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

INTRODUCTION TO INTERNATIONAL AGILE PRODUCT OWNER FOUNDATION Agile Product Owner... · 01 INTRODUCTION TO "INTERNATIONAL AGILE PRODUCT OWNER FOUNDATION" This course is the foundation

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

Falando Em Agile 2008: Product Owner and the Product Backlog

Business Analysts and Agile Development - Practical Guide

AgileME Dubai - Agile A-Z Chapter 2 - Product Owner

Product Owner Team - Agile Day Atlanta 2015

Agile Product Owner

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