scrum product owner certification - agile crossing · sprint backlog product release planning...

1

Certified Scrum Product Owner

www.agilecrossing.com

1


Instructor – Roger Brown CST, CSC

Training Transition

Transformation

All slides © 2014 Roger W. Brown 2

Course Objectives

You will learn about

The Scrum framework

Product Planning in Scrum

Product Owner responsibilities and practices

And you will be eligible for Scrum Product Owner Certification

3

Scrum Certification Options

Theory Practice Guide

Scrum Alliance is the largest,

most established, influential

professional membership organization in the Agile

world. As part of a growing

community of more than

350,000 members worldwide,

our members are helping us achieve our mission of

"Transforming the World of Work."

www.ScrumAlliance.org

4

CSPO Class Backlog

Scrum Foundations

Scrum Planning

Story Mapping

Product Vision

Product Roadmap

Prioritization Estimation User Stories

Story Splitting

Just-in-Time Elaboration

Portfolio Management

Product Backlog

Management

Product Ownership

Budget and Finance

Scrum Framework

Product Discovery

Must

Should

Could

Release Management

Working with the Dev Team

Working with Stakeholders

Working with the

ScrumMaster

Scrum Meetings

Focus and Flow

Other Prioritization

Tools

Class Vision

5

Scrum Framework

• Scrum has 4 meetings and 3 artifacts

• Scrum has 3 roles that share the

responsibility of creating value in small

increments

• The roles complement each other to create

a balanced team

6

Scrum Framework

Potentially Shippable Product

Increment

Sprint Backlog

Product Backlog

Release

Planning

Sprint

Planning

Sprint

Review Sprint

Retrospective

Daily

Scrum

Sprint

1-4

weeks

Story Time

2



7

Scrum Meetings

Sprint

Planning Sprint

Review

Daily

Scrum Sprint

Retrospective

1-4

weeks 2 – 4 hours 1. Which Items this Sprint? 2. Break down to sharable tasks

Fixed, repeating “time-box”

15 minutes - What did you do yesterday? - What do you plan for today? - Any blockers?

1-2 hours Public demo

1-2 hours Private process improvement recap

8

Sprint Timeline

Sprint 1 Sprint 2

Re

leas

e P

lan

nin

g Sp

rin

t P

lan

nin

g St

ory

Tim

e

Spri

nt

Re

vie

w\R

etr

osp

ect

ive

Continuous Elaboration of Product Backlog Items

Sprint N

Spri

nt

Pla

nn

ing

Sto

ry T

ime

Sp

rin

t R

evi

ew

\Re

tro

spe

ctiv

e

Spri

nt

Pla

nn

ing

Sto

ry T

ime

Sp

rin

t R

evi

ew

\Re

tro

spe

ctiv

e R

ele

ase

…

9

The Scrum Team

Desired Features

Product Owner

Development Team

Product

ScrumMaster

10

Product Owner

Maximizes the value of the work done

o Sets Vision o Manages Product Backlog o Elaborates Features o Reviews Work o Reports Release Progress

11

Development Team Member

o 7 ± 2 o Cross functional o Full-time o Self-organizing o Empowered

Develops the product with high quality

12

ScrumMaster

o Facilitator o Mentor o Coach o Leader o Change Agent

Helps the team improve flow

and throughput The ScrumMaster is the

Heart of Collaboration

3



13

notes

13 14

Product Ownership

• Agile provides benefits for business • The Product Owner job has three main

dimensions that make it a very large job for one person

15

Faster Time to Market Quicker ROI Lower Total Cost

Respond to Change Reduced Risk Stakeholder Relations

Agile Benefits for Business

16

Time

Pro

fit

competition

market penetration

customer feedback

innovation

compliance

internal stakeholders

market changes

The Product Owner balances competing demands to maximize value/time

Manage the Profit Strategy

17

Product Development Value Stream

Product Discovery

Product Definition

Product Development

Product Delivery

Product Operation

Support

Scrum/XP

Lean Startup

Lean UX

DevOps Kanban

Business success comes from maximizing value/time.

Which of these

involve the

Product Owner?

18

Define the Product

Build the Product

Plan the Product

It’s a Big Job

Corporate Strategy Portfolio Alignment Customer Needs Corporate Needs Competition Stakeholders

Product Vision Revenue Target

Product Backlog Priorities

Funding UX

Dev Team Collaboration Scrum Framework

Product Details Product Review

Release Plan

What else?

4



19

notes

19 20

Scrum Foundations

• Agile software development implements

Lean principles and dynamics

• The primary driver of Agile work is Value

• Scrum is one form of Agile, designed

initially for software development but

applicable to other kinds of work

21

Agile Manifesto

Manifesto for Agile Software Development 2001

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

www.agilemanifesto.org

22

What is Agile Software Development?

Dedicated Team Incremental Iterative Frequent Delivery Fully Visible Production Quality Value Driven

23

Estimates

Features

Schedule Cost

Plan

Driven

The Plan creates

cost/schedule estimates

Waterfall

The Vision creates

feature estimates

Schedule Cost

Features

Value / Vision

Driven

Agile

Source: Sliger and Broderick “The Software Manager’s Bridge to Agility”

Constraints

Value Driven

24

Continuous Improvement

Plan

Do Check

Act

Deming Cycle

Empirical Process Control Transparency, Inspect

and Adapt

5



25

notes

25 26

Scrum Planning

• Scrum planning is continuous

• Scrum planning happens at 5 levels, each

with a different time horizon

• The Product Backlog is the primary source

of work to be completed and value to be

delivered

27

Drawbacks of Traditional Planning

• Done when we know the least

• Written words become a commitment

• Too much information to grasp at one time

• Confuse “What” with “How”

• Details are open to interpretation

• Everything is Priority One

• Success is measured by adherence to schedule

• Not easily broken down to independent pieces 28

5 Levels of Planning

Strategy

Portfolio

Vision

Roadmap

Release

Sprint

Day

P1 P2 P3 P4 P5

Product Backlog

Release 1 Release 2 Release 3

s1 s2 s3 s4 … sN

Scru

m P

lan

nin

g

29

The Elements of Agile Planning

Product Backlog

Must

Should

Could

Won’t in this

Release

s1

s2

s3

…

sN

Release as often as possible

Newsworthy Release Event

Tim

e

Sprints

Priorities Which items are most valuable?

Velocity How much can the team complete in a Sprint?

Estimates How much effort is expected for each item?

Product Backlog What functionality Is needed for financial success?

30

notes

30

6



31

Product Vision

• The Vision describes the purpose of the

product to be created or enhanced

• There are several ways to present the

vision as a common goal for the Scrum

Team

• The Vision is the inspiration for the

Product Backlog

32

Product Discovery

• What is the target market? • Who are the target customers? • What are the sales channels? • What are the top benefits? • What are the pricing and revenue models?

We have newer Agile ways to do this

compared to traditional “Requirements Gathering”

33

Product Vision

• The Big Picture of how the product creates value

• Aligns everyone to the same goal

What is the name? Who is the target customer? What are the key benefits? What are the differentiating features?

34

Product Backlog

• Dynamic set of items to be done

• Prioritized

• Constantly in flux as the situation changes

Story

Story

Story

Spike

Story

Refactor

Story

Defect

Process Change

items are removed

priorities change

items are added

35

Vision Board

36

notes

36

7



37

Product Roadmap

• Road-mapping is a tool for creating a

longer term release strategy

• Roadmaps describe the product in very

high level terms

38

Product Roadmap

First sub-setting of Product Backlog for a long product development time frame

• How many releases?

• When?

• What is included in each?

Tim

e

Health Care Products

Information

Health Care Products Retail Sales

Health Care Products Wholesale

Sales

The roadmap will be reviewed and updated as things

change

Product Backlog

Releases

39

Product Roadmap – an example

Fajita Prescriptions and

Global Sales

Core

• Hippa

Community

• I8N

Shopping Cart

• Line of credit

Platform

• Mobile access

• For all users, wholesale RX • For all users, international

access • For BusDev, credit support

Q2 Q3 Q4

Core Engine

• Catalog

• API

Community

• Product rating

Shopping Cart

• Typical retail functions • Credit card support

Platform

• Transactions

• Billing

• For all users, retail sales for OTC products

• For providers, manual and API catalog access

Core

• CRM

Community

• Supplier ratings

Shopping Cart

• Purchase Order support

Platform • Scalable to 1M

transactions/day

• For all users, wholesale sales for OTC products

• For all users, retail sales for Rx products

• For Sales, CRM Functionality

Taco Retail Sales of OTC Products

Enchilada Wholesale Volume

Sales

Q1

Core Engine

• CMS

• Manual SEO

• Keyword Search

Community

• Article rating

Shopping Cart

Platform

• User accounts

• For all users, free access to linked and original content

• For writers, content management

• For Sales, SEO access

Nacho

Information Site to Build the Brand

Release name

and goal

Release date

Objectives by user and

feature area

Architectural Build-out 40

notes

40

41

User Stories

• User Stories are simple descriptions of

desired functionality

• Stories are elaborated just-in-time for

implementation

• Stories are used for planning

• The INVEST Criteria help us write good

stories

42

User Story Template

As a <user role>, I can <do something> so that <I get some value>.

Card – Conversation – Confirmation

8



43

Sample User Stories

As a registered user, I can purchase OTC products on-line so that I do not have to drive to the store

As a purchaser, I can print a receipt for a past transaction so that I can keep my own off-line records

As a purchaser, I can search for generic equivalents of name-brand items so I can save money

As a vendor, I can see monthly sales reports so I can see which products are selling best

44

Where are the details?

(front)

Story 6: Catalog Demo As a prospective user, I can browse the catalog to see if it has the kinds of products I am interested in.

(back)

Story 1 Acceptance Criteria [ ] Use standard design layout [ ] Has full catalog actions except for adding to shopping cart or wishlist [ ] Item click leads to product detail page with same restrictions [ ] Show product review star ratings only, no comments [ ] Call to action: “Become a Member” links to registration page

Automated Tests

Speclet • formula • UI design • business rules

45

Backlog Hierarchy

Epic User Story Task Task Task Task

User Story Task Task Task Task

User Story Task Task Task Task

Product Backlog

Sprint Backlog

Business Goal

Planning Implementation

46

INVEST Criteria for User Stories

I Independent Can deliver value by itself

N Negotiable Details can be worked out by conversation

V Valuable The value to the user is clear

E Estimable Dev Team understands it well enough to estimate

S Small Fits in one Sprint

T Testable We have clear test criteria

Bill Wake, 2003

47

User Story Tips

As a User…

As a <Scrum Role>

Who, How, What instead of Who, What, Why

Will it take more than 2-3 days?

Would a user really ask to do that?

? How can we know when it is done?

? How can we test it?

? How would we demo that at the sprint review?

> 1 And, Or, Plurals, Comma

> 1 Too many acceptance criteria (>12)

> 1 Too many tasks (>10)

INVEST

48

notes

48

9



49

Prioritizing

• Priorities help the Scrum Team decide

what to do next

• Priorities help with long term planning

• Prioritization can be done in many ways,

based on many criteria

50

The Right Product

What you deliver is much more important than how much you deliver!

$ $ $ $ $ $ $

$

$

$

51

Managing Value

Return on Investment =

Benefits – Costs

Costs

Cost is easy with a fixed team size and

Sprint length

Benefit is not so easy to

determine Elements of Business Value • Increased sales • Accelerated sales • Decreased expenses • Customer satisfaction/retention • External compliance • Market differentiation

52

Prioritization - MoSCoW

o Business value

• Acquisition

• Activation

• Retention

• Referral Revenue

o New knowledge

o Risk/Complexity

o Desirability

53

Theme Screening

+ = better than 0 = same - = worse than

Themes

Bu

y a

Pro

du

ct

(Bas

elin

e)

Man

age

C

ata

log

Co

nte

nt

Fin

d

Pro

du

cts

Sup

po

rt

Sup

plie

rs

Co

mm

un

ity

Fun

ctio

ns

Sele

ctio

n C

rite

ria

Draws new customers 0 + + 0 -

Generates Q1 revenue 0 0 - - -

Attracts Investors 0 - 0 + -

Builds out platform 0 + - + 0

Net Score 0 1 -1 1 -3

Rank 3 1 4 2 5

Continue? Y Y N Y N

Source: Mountain Goat Software 54

notes

54

10



55

Estimation

• Agile estimation is done at both the high

level and the low level

• Estimates are used for planning and for

tracking progress

• Estimates are done quickly, by the

Development Team

• Estimates are not commitments

56

Story Estimation Basics

Quick

Story 1: Home Page As a prospective user, I can view the home page so that I can decide if I want to try the service.

2 Story 17: Generics

As a purchaser, I can search for generic equivalents of name-brand items so I can save money

5

Quick

Relative

Guess

Done by Dev Team

More than 2x effort required

57

Velocity

5

12

27

32

36 38

40 37 38

40

0

5

10

15

20

25

30

35

40

45

1 2 3 4 5 6 7 8 9 10

Sto

ry P

oin

ts C

om

ple

ted

Sprint

Team Velocity

How many story points can the Team complete in a Sprint?

Varies by circumstance, increases with

experience

Aggregates Team dynamics and organizational

factors

Is measured, not “managed” Velocity is sum of

estimates of stories completed

58

Using Agile Estimates

How much we have to

do

How much is

done

Forecast of scope that

will be completed

59

notes

59 60

Story Splitting

• Smaller stories are easier to work with and

enhance flow

• Smaller stories gives us more options to

reduce scope

11



61

Smaller is Better

20

5 3 5

Smaller Stories are easier to

work with

Increased Throughput

• helps flow

• quicker feedback

• unbundle priorities

Decreased Complexity

• easier to estimate

• fewer test cases

• easier to focus

• cleaner designs

62

Vertical Slices

Front End (UI)

Middle Tier (Business Logic)

Back End (Data)

Use

r St

ory

2

Use

r St

ory

1

Each story will should deliver

end-user value.

Sam

ple

Arc

hit

ect

ure

Sta

ck

63

Two Levels of Scope Control

Epic 1 Epic 2 Epic 3 Epic 4

In Scope for Release Out

64

Story Splitting Patterns

• Workflow Steps • Business Rule Variations • Major Effort • Simple/Complex • Variations in Data • Data Entry Methods • Defer Performance • Operations (CRUD) • Spikes

http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

65

notes

65 66

Story Mapping

• Story Maps are a 2-Dimensional

representation of the Product Backlog

• Story Maps are an easy way to visualize

what is in and what is out of the next

release

12



67

Story Map

Epic

I can browse by

type

I can search by product

name

I can add to my cart

I can check out

I can browse by

sku

I can remove

from cart

I can browse by

price

I can see total with shipping

I can save for later

I can search by company

I can search by barcode

I can buy things

Browse Search Cart Transact History

I can move items to wish list

I can print an old receipt

I can get month’s

total

I can browse by popularity

Theme

Must

Should

Could

Pri

ori

ty

I can print the receipt

68

notes

68

69

Product Backlog Management

• A well-managed Product Backlog keeps the

Development Team running smoothly

• A 1-sprint look-ahead on stories will help

the flow

• The Team needs details Just In Time

• Defining Ready and Done will dramatically

reduce time waste

70

Backlog Grooming

Product Owner spends 30% of their time working on the Product Backlog

• Identify new stories

• Splitting epics and stories

• Updating Release Plan with current velocity data

• Adjusting priorities

• Preparing next stories

• Designing user experience

71

Story Time

Development Team spends 5-10% of Sprint with the Product Owner preparing for the next Sprint

• Reviewing candidate stories

• Getting details and acceptance criteria

• Some technical design

• Looking at new stories

• Considering new ideas

Often a regular meeting 1 hour/week

or 2-3 hours mid-sprint

72

Definition of Ready

Negotiate with your Team - What they need for each story - When they need it

Sample Right size Screen sketches Acceptance criteria Dependent stories? Speclets INVEST

13



73

Definition of Done

• When estimating size, consider all the work needed to complete the story

• The Definition of Done may evolve over time

Sample

Can also have one

for sprints and

releases

Unit tested to 90% coverage

Code reviewed Acceptance tests pass UI Tested User Help updated Scales to 1 Million Users Meets current response time targets

74

Sprint Flow

Sprint N Sprint N+1

Candidate Stories for N+1 (1.5 x velocity)

Definition of Ready

Screen Designs for N+1 (LoFi)

Continuous Product Backlog Grooming

Story Time Sprint Planning

Definition of Done

75

notes

75 76

Just-in-Time Elaboration

• Story elaboration is done just in time to

reduce wasted time defining details that

may never get used

• Details are provided to the Development

Team as conversations, acceptance criteria

and speclets

• Details may also lead to story splits

77

Elaborating Stories

As a user, I can get a receipt for a past transaction so that I don’t have to keep a paper copy

• How far in the past can data be retrieved?

• How can the transaction be identified?

• Can the receipt be printed?

• Can the receipt be emailed?

• The receipt will be itemized with a total, date

and purchases contact information

• Can the user re-order the same items easily

while looking at the receipt on-line?

78

Details as Acceptance Criteria

(front) As a user, I can get a receipt for a past transaction so that I don’t have to keep a paper copy

(back) Data are available for 3 years User can search by date User can search by order number User can search by item name etc…

14



79

Details as Smaller Stories

As a user, I can get a receipt for a past transaction so that I don’t have to keep a paper copy

As a user, I can print a past receipt to file for my tax records

As a user, I can have a past receipt e-mailed to me so that I can forward it to my accountant

80

Acceptance Criteria Alternate Form

As a purchaser, I can print a receipt for a past transaction so that I don’t have to keep a paper copy

Given

• that a purchaser has one or more transactions

• And she is viewing her payment history

When

• She clicks on the line item for one transaction

Then

• A purchase detail page will be shown

• Using the format sketched in attachment A.

• With a “Print Receipt” button that presents a printable

receipt in a pop-up window

• Having a “Print” button that invokes the browser print

function

This is called “Gherkin” Format, a newly popular normal form

81

Speclets

personalize

show local time

show state of sales tax

82

notes

82

83

Release Management

• There are two basic product release

strategies based on time and scope

• Risk is reduced by including slack in the

plan

• Release tracking and forecasting are based

on real data about actual product

completed

84

Release Plan

s1

s2

s3

…

sN

Product Backlog

Release as often as possible

Newsworthy Release Event

Tim

e

Release Backlog

Must

Should

Could

Won’t in this

Release

Sprints

Release Plan 1. How long will it

take or 2. how many can we

do by a given date?

Release Forecast:

1. How Long? Number of Sprints = Total Backlog/Average Velocity 2. How Much? Percent of Backlog = Total Backlog/(Average Velocity * Number of Sprints)

Include extra Sprints to handle the unexpected

15



85

Feature-Based Release Strategy

Release Backlog

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Release 1: Conventional health care products

Release 2: Alternative health care products

Release 3: health care services

When will it be done?

86

Time- Based Release Strategies

Release Backlog

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Q1 Release

Q2 Release

Q3 Release

How much will we complete?

87

The Importance of Slack

6 1 2 8 6

From Slack – Tom DeMarco

• 30 – 40 % of schedule overrun comes from emerging requirements

• Change needs room

• Pressure does not speed up work

• People are not Plug & Play

• Cannot plan for the unexpected

• Leave room for new ideas

1 8

7 3

4 5 2

6 1 2 8 6 1

8 7 3

4 5 2 9

88

Visibility

The more we know, the better we can

adapt And the better we can manage risk

Report what we know, not what we hope

89

Release Planning Meeting

Align Vision

Identify User Roles

Identify features/Epics

Brainstorm User Stories

List Priority Criteria

Prioritize Stories

Estimate Stories

Check Priorities

Forecast Team Velocity

Forecast Release 1-2 days

90

notes

90

16



91

Working with the Development Team

• The Dev Team may propose stories for the

Product Backlog

• Teams take time to mature

• The Dev Team is self-organizing

• Awareness of effective motivators can help

build a high performance team

92

Dev Team Priorities

Performance Boost Refactor the transaction engine to handle 10,000 per second

Stories may come from the Team

Technical Debt can slow down development

93

Establishing Goals

• Product Vision • Why are we doing this?

• Release Goals • Quality, function, process, performance • Make them SMART

• Sprint Goals • Overall goal is much more than just

completing the tasks

94

Tuckman's Team Development Model

Storming

Forming

Norming

Performing

• Teams go through four stages

• Teams can regress when membership changes

Time

Effe

ctiv

en

ess

Applies to the Development Team and the whole Scrum Team

95

• Financial rewards often give poor results • Intrinsic vs. extrinsic motivation • People are motivated by

• autonomy • mastery • purpose

See Dan Pink, TED.com and Drive

Motivation

96

notes

96

17



97

Working with the ScrumMaster

• The ScrumMaster is your partner in

achieving a smooth flow and continuous

improvement

• The ScrumMaster is a productivity

multiplier for the Team

98

Value of the ScrumMaster

Manage impediments Facilitate meetings Mediate and negotiate Teach Scrum Manage the process Assist the Product Owner

Observe and coach Team Encourage excellence Protect Team from distractions Build relationships Promote Organizational Agility Administer

ScrumMaster 7 Team Members Productivity

99

notes

99 100

Working with Stakeholders

• Customers are not your only Stakeholders

• You can’t please everyone all the time

101

Agile Team

Product Ecosystem

Desired Features

Product Owner

Development Team

Product

ScrumMaster

Execs

Identification Prioritization Elaboration Innovation

Sprint Review Validation Delivery

Consultation Strategy Refinement

Customers

Marketing Ops

102

Who are your Stakeholders?

• Customers • Other end-users • Upper Management • Marketing • Sales • Operations and Support • Who Else?

18



103

Balancing Priorities

• Stakeholder Preferences • Internal and external • Politics: is each one represented?

• Strategic Alignment • Some stories map directly to corporate goals

• Driving Profit • Value Exchange Model

• How do you trade money for value? • Ex. transactional, licensed

• Profit Engine • How do you enable people to buy more? • Ex. freemium, standards, value-add services

From Luke Hohmann, Enthiosys

104

notes

104

105

Scrum Meetings

• Scrum organizes work into 1-4 week time

boxes called Sprints

• Each Sprint has 4 primary meetings

• The bulk of the time is spent creating value

in the form of a product

106

Sprint Time Box

S1

1-4 weeks

Steady cadence, fixed length

Focus No one can change the Sprint plan except the Scrum Team to add or

remove a PBI

S2 S3 S4

Abnormal Termination If the Sprint Goal cannot

be reached for unexpected reasons, stop and plan a new

Sprint

107

Sprint Planning Meeting

Product Backlog

Sprint Backlog

Pri

ori

ty

Goal 1: What? • Which PBIs can will comprise our forecast? • What is our Sprint Goal? Ex. Build the shopping cart

Goal 2: How? • Design an implementation plan, often by decomposing into tasks • Double check our forecast

Attended by • Product Owner,

Development Team, ScrumMaster

• Other interested stakeholders

Time-box to 1 hour per week

of Sprint

108

Daily Scrum

15 Min

The Three Questions What did you do yesterday? What do you plan to do today? Is anything blocking you?

19



109

Task Board

Sprint Burndown

Daily Progress and Planning

Item

110

Sprint Review

• Purpose • Get feedback from the Stakeholders

• Demonstrate the completed stories

• Review progress and adjust future

• Identify new/changed features

• Attendees • Product Owner, Development Team, ScrumMaster

• Any other stakeholders

Preparation • Who will show what? • Deploy to a preview server • Any documentation needed? • Update and show release burnup chart

2 Hours

Show actual running

code!

111

Sprint Retrospective

• Scrum Team meets privately

• Goal is process improvement

• Format

• Review results of previous experiments

• Gather Data

Reflect on what worked well, what didn’t

• Generate Insights

Discuss results and new ideas

• Decide Action Items

Consider adopting new practices

Stop doing things that are not working

1.5 Hours

Stop Start Continue

Keep it interesting • Appreciations • Food • Variety

112

notes

112

113

Budget and Finance

• Budgeting relies on Release Planning

• Velocity is the primary unknown in budget

requests

• Some organizations are moving to more

Agile budgeting models

114

Quicker Return on Investment

20



115

Estimating Release Cost

s1

s2

s3

…

sN

Release Backlog

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

sM-1

sM

Ex. Sprint cost is cost of people on the team for 2

weeks

“Must Have”

Stories

“Could Have”

Stories

“Should Have”

Stories

Planned scope = 300 sp

Forecast velocity = 30 sp

Planned Sprints = 10

Sprint cost = $100,000

Release Cost = $1,000,000

116

Cone of Uncertainty

Agile release forecast improves with each Sprint based

on actual data as the Team matures.

Esti

mate

Vari

ab

ilit

y

117

Initial budget request is based on cost estimate for 2 Releases

Product becomes self-funding in

Release 3

Denne, Mark; Cleland-Huang, Jane (2003). Software by Numbers: Low-Risk, High-Return Development.

Incremental Funding

118

Annual budgeting, like Waterfall development, is at odds with innovation, adaptability and responsive investment. • Success is defined by keeping to the budget at any cost • Sales targets trump customer sat • Internal competition with other products • Risk aversion • Ask for more than you need and always spend it all • Product maintenance cost is someone else’s problem

http://www.bbrt.org/

• Common Cause

• Transparency

• Self-managed Teams

• Ambitious Goals

• Reward financial performance

• Continuous Planning

• Just in time resourcing

• Manage by feedback

Beyond Budgeting

119

Defer commitment until the last responsible moment • Take steps to increase knowledge and stop early

if assumptions are proven false • Invest incrementally as assumptions are

confirmed • Reallocate capital based on new knowledge

Reduce budget cycle 12 mo – 6 mo – 3 mo –

1 month

Rudd, The Business Case for Agility

Real Options

120

notes

120

http://www.bbrt.org/

21



121

Product Discovery

• Agile Teams may build product faster than

traditional methods can discover user

needs

• There are few more Agile methods for

finding customer needs

122

Lean Startup

• Parallels or proceeds product development • Find out who your customers are • What kind of market are you in? • What is the Minimum Viable Product? • Phase product with company growth • Iterate to Learn

123

Innovation Games

Product Box

Speed Boat

Me and My Shadow 124

Pragmatic Marketing

Tune into the Market. Gain practical techniques for learning about your market and competitors. Discover tools and techniques that allow you to identify the entire market, listen to it and become its messenger.

- http://www.pragmaticmarketing.com

125

Lean UX

User Research

Design Studio

Story Maps

126

notes

126

22



127

• Agile and Scrum concepts can be applied

at the product portfolio level

Portfolio Management

128

Teams Increase Value/Time

Finance Teams Not Projects

129

Portfolio Team

Product 1 Product 2 Product 3 Product 4

• Manage allocation of investment in products

• Product Owner is Upper Management

• Members are project Product Owners

• Backlog is Product releases

• Priorities can change

• Teams can be re-allocated to different products

Portfolio Level Scrum

130

Balance investment in Project Types • Support the org • Grow the business • Create new opportunities

Stop Starting Start Finishing

Rank products/projects by value

Don’t throw good money after bad

Reduce the budget cycle for greater agility

Rothman, Manage Your Project Portfolio: Increase Your

Capacity and Finish More Projects

Portfolio Management Tips

131

notes

131 132

Other Prioritization Tools

• Relative Weighting can be applied to

Stories

• Financial Projection can be applied to

Releases and Features

• Innovation Games can quickly get input

from your customers

23



133

Prioritization Factors

Factors to consider • Value

• How much revenue will it generate? • How much present cost will it save?

• Cost • The estimation process gives us a figure • May change with time of delivery

• New knowledge • About the project (means) • About the product (ends)

• Risk • In schedule, cost, functionality • Business or technical

134

Relative Weighting

Relative Weighting applies at the story/feature level

- Choose a manageable set of features

- Assemble a set of Subject Matter Experts

- For each feature, query the SMEs to give a 1-9 weight to

• How much benefit is there if this is implemented

• How much penalty is there if this is not implemented

- Create the summary chart and add estimates of cost to get the value to cost ratios as a priority indicator

135

Relative Weighting Calculation

• Benefit and penalty may be weighted differently

• Add benefit and penalty to get total value

• Priority = Value % / Cost %

Source: Agile Estimating and Planning, Mike Cohn

136

Financial prioritization (Profit and Loss Statement)

• Look out N years (product lifetime)

• Estimate • New revenue

• Incremental revenue

• Retained revenue

• Operational efficiencies

• Balance with development cost to get net cash flow

• Approaches • Net Present Value

• Internal Rate of Return

• Payback Period

Source: Agile Estimating and Planning, Mike Cohn

Financial Projection

137

Innovation Games

Buy a Feature

Prune the Product Tree

20/20 Vision

138

Kano Analysis

Kano Analysis applies at the theme level - Group features into

- Threshold (must have) - Linear (the more, the better) - Exciters (drive people to buy)

- Get opinions from - Experts - User Survey

24



139

Kano Survey

• Small user sample is sufficient

• Ask both functional

• What if this feature is included?

• … and dysfunctional questions

• What if this feature is missing?

• Categorize and aggregate results

• In your product include

• All threshold features

• Some linear features

• A few exciters

Agile Estimating and Planning – Mike Cohn

140

notes

140

141

Focus and Flow

• Scrum works best when the Team

achieves a smooth flow of work

• Scrum dynamics are based on the

mathematics of queuing theory that we

use to manage the Internet

• Continuous improvement is an

underlying goal of Scrum

142

Push systems overwhelm capacity, creating turbulence, rework, waste and delay

Pull systems have a steady flow that provides predictability

Push

♫

Pull Systems

143

Small Batches

Small batches move through

a system quicker

Single-piece-flow reduces the wait time

and moves risk to the

margin

Minimize work in progress

Item

144

notes

144

25



145

Close

• Parking Lot

• More information for Product Owners

• Wrapping up

146

Learn More

• Forums • http://groups.google.com/group/scrumalliance

• http://groups.yahoo.com/group/scrumdevelopment/

• Certified Scrum Product Owners’ group on LinkedIn

• Self-study

• Local Scrum Groups

• Scrum Gatherings

147

Certification

Mini-Exam

Class Evaluation

Class Picture

148

Instructor

Roger Brown

• Agile Coach

• Scrum Alliance

Email: [email protected]

Twitter: rwbrown

Blog: www.agileCoachJournal.com

LinkedIn: http://www.linkedin.com/in/rogerwbrown

V2.5

149


Instructor – Roger Brown CST, CSC

Training Transition

Transformation

All slides © 2014 Roger W. Brown

http://groups.google.com/group/scrumalliance

http://groups.yahoo.com/group/scrumdevelopment/

mailto:[email protected]

http://www.agilecoachjournal.com/

http://www.linkedin.com/in/rogerwbrown

http://www.linkedin.com/in/rogerwbrown

scrum product owner certification - agile crossing · sprint backlog product release planning...

Documents