agile product owner

Agile Product Owner

The Goal

What is the goal of software development?

Hint: It is not to produce working code

It is to make a profit

Product Owner Role

How would you describe it?

Define a successful product.

Sets the product direction at all levels

Represents the customer and business domain on the team

Represents the product to the customer

CEO of the product

Manages the Product Backlog

Product Owner Role

Responsible for market, business case, and competitive analysis

Captures most of the User Stories and their Acceptance Criteria

Prioritizes in a stack rank the User Stories for releasesbased upon expected ROI

Accepts (or rejects) User Stories on behalf of the Customer

Product Owner Role

Responsible for ROI, Cost and Net Profit

Higher operating expense in longer release cycles

Scope impacts business value in Expected ROI

Chooses the mix of features for releases

The most value

in the smallest scope

within the shortest time

Product Owner Challenges

1.Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself.

2.Resisting the temptation to add more work

3.Being willing to make hard choices during a planning meeting.

4.Balancing the interests of competing stakeholders.

Pig or a chicken?

Originally the Product Owner role was considered a chicken role. That’s to say it was a role that required no commitment to the Sprint goals. This has changed over the past as the product owner role has been identified as a key to success or failure of a project.

Product over Project

Always7%

Often13%

Sometimes16%

Rarely19%

Never45%

Standish Group study reported at XP2002 by Jim Johnson, Chairman

Often or Always Used: 20%

Rarely or NeverUsed: 64%

Plan Design Build Test

Release

Bug Fix

exemplify

validate

release

innovate

Inspect & Adapt

v2.0 v2.1 v2.2 v2.3 v2.4

Plan Design Build Test

Release

Bug Fix

ChangeRequest

start finishproject timeline

Point where finding defects least desired.

v2.0 v2.1 V3.0

Change

v2.15

Change Change Change

v2.2

Value over Date over Scope

Value Rolls Up

Suite - Interrelated products and platforms

Product - Satisfies a market need

Release - Deployed feature set proving value

Feature - Minimal and marketable set of Stories

User Story - Smallest block of customer value

Steering the Planning

Driving as a Metaphor

Where are we heading?

Continuously adjust steering based on feedback from the road.

Make turns down roads to reach the destination, get by obstacles, or when changing course.

Rolling Wave Planning

Product

Larger ideas are further away and detailed out as the date nears.

6-12 monthsahead

Release 3-6 monthsahead

Feature2-4 weeksahead

Vision Planning Wave

Scope - For Multiple years Are the Vision and Mission statements fresh? Are the objectives in line with these statements?

Updated - Every year

Results of plan Vision and mission shared internal and external Status on objectives updated and communicated

Product Planning Wave

Scope - AnnuallyWhat objectives will be addressed?What is the compelling statement of need?

Updated - Each Quarter

Results of plan Establish time-to-market commitments Product roadmap One-pager for each product

Product One Pager

Elevator Statement

For…who…that…Unlike…

Customer Attributes

1. People who work in …2. Those who need a …3. …

Feature / Ability to…

1. Share content with…2. Personalized ads on…3. …

Metrics:

Sign-ups xxx

Customer Benefits

1. More accurate …2. Better customer service …3. …

Performance Attributes

1. 3000 hits/hour2. …

Tradeoff Matrix

Scope

Resources

Schedule

Quality

Fixed Firm Flexible

√

√

√√

Major Milestones

Xyz features xxxAbc features xxx

Metrics and ROI

Release Planning Wave

Scope - Quarterly What needs to be released next? What is the size of the release?

Updated - Monthly Re-evaluate plan, make adjustments, notify stakeholders Derive duration based on size of Stories in release

Results of Plan People organize in to feature teams Minimal features to market established Update schedule of release window

Collecting features into releases for scheduling is your primary planning tool

Feature Planning Wave

• Scope - Monthly• What User Stories comprise this feature?• How do we know when the feature is done?

Updated - Weekly Revisit the backlog and keep highest-valued User Stories

at the top.

Results of plan Break down a feature into stories Write initial acceptance criteria for stories Team estimates size of stories to derive duration Inestimable stories are identified as a ‘spike’ Logically group features in to a theme if needed Prioritize stories in the team’s Product Backlog

Story Planning Wave

• Scope - Every Sprint• What tasks are needed to deliver this story?• How do we know when the story is done?

Updated - Every day Ensure tacit knowledge of high-rank user stories is strong Stories updated to reflect tasks needed

Results of plan Break down a story into tasks All tasks needed for delivery identified Story can be delivered as working software

Work Planning Wave

Scope - Daily• What did I finish yesterday?• What am I doing today?• What is in my way of finishing?

Updated - As tasks finish• Update work board to reflect what is being worked on• Ensure tasks prove out acceptance criteria

• Results of plan• Identify bottlenecks to work-in-progress• Swarm on tasks to complete User Stories

Multi-year Vision

The Waves Combined

Yearly Product

Quarterly Release

Monthly Feature

Sprint Story

Daily Work

Multi-Level Planning

Product Vision

Roadmap

Release Plan

Sprint Plan

Daily Plan

Q1 Q2 Q3

R1 R2 R3

Relative Sizing

1 2 3 58

13

20

40 100

The rate of change in displacement with respect to time.

It has both magnitude and direction.

Velocity Formula

How difficult is the journey?

8 minutes

12 minutes

1 mile

Velocity

Cone of Uncertainty

A story point takeoff chartP

oint

s

What can I have?Desired

release date1 July

Today’s Date 12 February

Number of sprints

10 (2 week length)

Worst 12

Average 22

Will have above

Wont have below

10x12=120

10x34=340Last 26

Best 34

Very likely to have

10x22=220Pretty likely to have10x26=260

Last (26)

When can I have it?

Total Points 150Today’s Date 12 February

23 April Best (34)7 May

Average (22) 21 MayWorst (12) 30 June

150/12=12.5

150/22=6.8

150/26=5.7

150/34=4.4

2/12 4/23 5/21 6/30

Releases cover multiple iterations

44

3

4

2

1

3

V = 21

32

1

54

3 3

V = 21

Story A

4

Story B

4

Story C

3

Story D

3

Story E

2

Story F

4

Story G

3

Story H

2

Story I

3

Story J

3

Story K

4

Story L

1

Iteration 1

Iteration 2

ready to deliver

Planning

Analysis

Design

Coding

TestingPerformanc

e User Acceptance

Staging

Live

May require a Release SprintAKA “hardening”

Fit and finish

Shrink Wrap

Intensive customer involvement

Suggested for immature Sprint teams

Release Planning

R1 R2 R3

Incremental Releases Users and Stakeholders Will Love

How to deliver functionally complete, valuable, incremental releases

Jeff [email protected] is held by the author/owner(s).OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA.2006 ACM 06/0010.

Software By Numbers & Project Portfolios

Software by Numbers [Denne & Cleland-Huang] describes Incremental Funding Methodology [IFM]

Goal to reduce necessary cash outlay

Make projects self-funding

Increase return on investment

SBN Tools:

http://dactyl.cti.depaul.edu/ifm/default.htm

SBN introduces the concept of Minimal Marketable Feature – MMF - the smallest sized feature that would have marketable value

SBN simple financial models provide guidance on evaluating multiple projects in a portfolio

http://dactyl.cti.depaul.edu/ifm/default.htm

A Lot Can And Does Go Wrong During Design And Development

process risks

delays & cut scope

scope additions

scope subtractions

design not built as described

risks from outside the process

political

financial

loss of key talent

A Lot Can And Does Go Wrong At Release Time

design off target – doesn’t meet user or business goals

product made unusable by poor performing technical architecture

ROI estimates were big fat lies

Using Our Task Model to Identify Features that Span Our Business ProcessThe Task Model we’ve built identifies the major activities and tasks that span the business functionality

A successful software release must support all necessary activities in the business process

This type of task model is referred to as a Span Plan since it helps identify the spans of functionality

Task 1 Task 2 Task 3 Task 4 Task 5

Task 6 Task 7

time

nece

ssity

Activity 1

smallest list of tasks to support users = smallest span

Identify Releases In a Span Plan By Slicing Horizontally

Choose coherent groups of features that consider the span of business functionality and user activities.

Support all necessary activities with the first release

Improve activity support with subsequent releases

time

optio

nalit

y

necessary

lessoptional

moreoptional

activity 1 activity 2 activity 3 activity 4

first release

second release

third release

This Product Thickening Strategy Slowly Brings The Product Into FocusJust as an artist envisions an entire painting by starting with a

sketch or an under-painting and slowly building up detail, apply the same strategy to “thicken” the product from simple necessities through to full featured product.

Project Success is Not Product Success

Placing focus on finishing all scope on time and in budget may equate to project success

Finishing all intended scope on time, and under budget does not guarantee product use or quality of use

Focus on effective support of user tasks

Focus on achieving stakeholder and user goals

Focus on getting product into use to begin earning revenue for its business stakeholders

Agile development may be characterized by short cycles of planning and design, building, and testing and evaluation.--Jeff Patton

Minimal Marketable Feature

A A feature is minimal because if it was any smaller, it would not be marketable.

It is marketable because when released to production, customers will use it.

Retu

rn o

n R

even

ue

Months to complete 1

112

13

Release 2

Release 1

Release 3

14

15

16

Different Types of Features

Table Stakes

Parity to the competition

Minimum needed to be in the game

Delighter

Differentiates you from the competition

Excites the customer

Spoiler

Competitor’s advantage

Raises the bar for parity

Pain Reliever

Reduces Cost

Improves the margin

Features are Supported By Architectural Elements

From Themes to Features

5

13

3

13

8

5

8

8

5

2

13

8

5

8

13

2

20

5

13

8

5

13

20

8

5

13

3

13

8

5

8

852

13

8

5 8

13

2 20

5

13

8

513

20

8

Prioritizing Features

High

High

Low

Low

Ris

k

Value

1

23

X

Force-rank Features on a Product BacklogDeploy highest value

Maximize throughput

Maximize ROI

De-scope lowest value

When date is fixed

Adjust to competition

Adjust to emerging features

Focus the effort to get Stories done/shippable

KISS

Swarm

4 Release Strategies for the Same Product Features

Single Release12 months

total cost: $1.3 Mtotal 2 year return: $3.6 Mnet 2 year return: $2.3 MCash Investment: $1.3 M

Internal Rate of Return: 9.1%

Semi Annual Release6 months increment

total cost: $1.4 Mtotal 2 year return: $4.8 Mnet 2 year return: $3.4 MCash Investment: $.7 M


Quarterly Release3 months increment



Quarterly Release – drop the last release3 months increment



Quarterly Release – continue with 5th release3 months increment

total cost: $2 Mtotal 2 year return: $6.2 Mnet 2 year return: $4.24 MCash Investment: $.44 M

Internal Rate of Return: 19.0%Source: Jeff PattonIncremental Releases Users and Stakeholders Will Love

All features delivered and in use earn $300K monthly

About half the features account for $200K of this monthly returnFeatures begin earning money 1 month after releaseEach month of development costs $100KEach release costs $100K

Technical Considerations

Continuous Integration

Build on demand

Execute all tests

Build integrity in

Progressive design

Implemented with end-to-end functionality

Exemplified through test coverage and refactoring

Scaling the Product Owner

ProductOwners

Product LineOwners

Chief ProductOwner

Who has the ‘D’?