Rawsthorne | Who is your PO

Dan Rawsthorne: Product Owner 12/9/2009

Danube Webinar 1

© 2009

The Secret of Success

Product Owner

Dan RawsthorneCertified Scrum TrainerSenior CoachDanube Technologies, [email protected]

Agile Days ‘09, Moscow

December 9, 2009

© 2009

Topics to Cover

� How Scrum Works

� Who/What is the Product Owner (PO)?

� Responsibilities of the PO

� Summary

� Discussion

Product Owner by Dan Rawsthorne 2


Danube Webinar 2

© 2009

Why the Product Owner is Important

� According to the Standish Group, the following Table

represents the primary success/failure criteria for Software

Projects

SUCCESS CRITERIA POINTS

1. User Involvement 19

2. Executive Management Support 16

3. Clear Statement of Requirements 15

4. Proper Planning 11

5. Realistic Expectations 10

6. Smaller Project Milestones 9

7. Competent Staff 8

8. Ownership 6

9. Clear Vision & Objectives 3

10. Hard-Working, Focused Staff 3

TOTAL 100


© 2009

How Scrum Works



Danube Webinar 3

© 2009

Sprint/Iteration

DailyStandup

Sprint/Iteration

Reports/

Metrics/

Impediments

Backlog

Sprint

Backlog

Increment

of Work

ResultsSprint Review

Retrospective

Sprint

Planning

Mechanics of Scrum: Flow Each Sprint


© 2009

Why Scrum Succeeds

� Empirical (agile) Process – Detailed up-front planning and defined processes are replaced by adaptive inspect and adapt cycles (product and process)

� Changeable Code – we know how to write code we’re not afraid to change

� Strict Accountability Model – one person on each Team (the PO) is accountable for the Team’s product

� Self-Organization – team is self-managing and organizes itself around goals given constraints



Danube Webinar 4

© 2009

Who/What is the Product Owner?


© 2009

Straight to the Source – Ken Schwaber

� The Product Owner is the leader of the Scrum Team

� “The [Product Owner] is responsible for what the scrum team builds and for

optimizing the value of it.” (The Enterprise and Scrum, 2008, pg 114)

� “[The Product Owner] is the person who is officially responsible for the

project… everyone in the organization has to respect his or her decisions.

No one is allowed to tell the Scrum Teams to work from a different set of

priorities, and Scrum Teams aren’t allowed to listen to anyone who says

otherwise.” (Agile Software Development with Scrum, Schwaber and

Beedle, 2002, pg 34) [ed: emphasis mine]

� The Product Owner is the “single, wringable, neck” (The Enterprise and

Scrum, 2008, pg 6)

� There are two additional caveats

� The Product Owner IS a member of the Scrum Team

� The Product Owner IS NOT the ScrumMaster

� But I’ll tell you a story about this one later…

� This is it. This is all. Everything else is just noise…



Danube Webinar 5

© 2009

The Basic Scrum Engine (Scrum Team)

Business

Owner

Scrum

Master

Product

Owner

Stakeholders

SME

SME

SME

SME

Product Owner is the Key

As a Person

� Single-Wringable Neck

� Decides on Releasability

As a Role

� Stakeholder Management

� Vision, Goals, and Features

� Release Planning

� Drives the Team

� Understands ROI

� Prioritizes Stories

� Acts as SME, or brings them in

� Drive the Team


© 2009

Getting Work Done (the RASCI model)

R esponsible – the Team members are Responsible for the work

the Team committed to

A ccountable – the Product Owner is the only Team member

Accountable to the Business for the work the Team has

committed to

S upportive – The ScrumMaster is Supportive of the Team by

facilitating its self-organization, coaching in scrum, removing

impediments, and so on…

C onsulted – external Subject Matter Experts (SMEs) are

Consulted by Team members if necessary. No one outside the

team is either Responsible or Accountable for work the Team

has committed to

I nformed – all external Stakeholders are kept Informed of what

the Team has committed to, and the progress the team

is making



Danube Webinar 6

© 2009

Product Owner vs ScrumMaster

� The PO is "The person who is responsible for what the scrum team

builds and for optimizing the value of it." (The Enterprise and Scrum,

pg 114)

� “The ScrumMaster is responsible for the Scrum process, its correct

implementation, and the maximization of its benefits” (Agile Project

Management with Scrum, pg 142)

� “In particular, the ScrumMaster is responsible for teaching the PO how

to most effectively manage the work of the Scrum team … and meet

their objectives through scrum." (The Enterprise and Scrum, pg 78)

� The PO and SM go together

� “like peas and carrots” (Forrest Gump)

� “like a horse and carriage” (Frank Sinatra)

� “like milk and cookies” (Santa Claus)


© 2009

“Project Fury”Management

TeamProject Manager: Fiona

“Product H-12”Management

TeamProduct Manager: Hugh

“Project Gold”Management

TeamProject Manager: Gerry

“Pirates”DevTeam

Team Lead: Pete

“Project Silver”Development

TeamProject Manager : Susan

Team Lead: Stan

“Warriors”DevTeam

Team Lead: Wendi

“Tigers”DevTeam

Team Lead: Tanvi

“Bears”DevTeam

Team Lead: Bhanu

“Lions”DevTeam

Team Lead: Lars

SMEsOffice

Staff

Organizational Examples

� There are many Product Owners here, if the organization is

managing itself using scrum

� These people will have to learn the scrum way of doing things

� The people don’t change, the way they work changes…

These people

Are POs. It’s not

A choice – it’s a

definition



Danube Webinar 7

© 2009

Managing with Scrum

� Organizational Teams

� Project Management Team

� Dev Teams

� Scrum Teams (potentially)

� Project Management Team

� Dev Teams

� Product Owner Teams (virtual)



“Product H-12”Management

TeamProduct Manager: Hugh



“Project Silver”Development

TeamProject Manager : Susan

Team Lead: Stan

SMEsOffice

Staff



“Pirates”

DevTeamTeam Lead: Pete

“Warriors”

DevTeamTeam Lead: Wendi

Project Gold

PO Team


Product H-12

PO TeamCommunicate

Cooperate

Coordinate

© 2009

Managing the Backlog

� One thing these PO Teams could do is manage a joint backlog

� The following is a simple example of what this could look like

� The Team’s Backlog may only consist of the Sprint Backlog, or

could be more of it…



“Tigers”

DevTeamTeam Lead: Tanvi

“Bears”

DevTeamTeam Lead: Bhanu

“Lions”

DevTeamTeam Lead: Lars

TeamBacklog

TeamBacklog

TeamBacklog

MgmtBacklog

UnallocatedBacklog



Danube Webinar 8

© 2009

Could also have other Virtual Teams

� Like Scrum Master Teams. Here’s an example…

� The SM Team would be there for managing cross-team

impediments, and so on

� This is “Scrum of Scrums” Pattern



ScrumMaster: Rob

“Tigers”

DevTeamTeam Lead: Tanvi

ScrumMaster: Joe

“Bears”

DevTeamTeam Lead: Bhanu

ScrumMaster: Pavel

“Lions”

DevTeamTeam Lead: Lars

ScrumMaster: Martin

Project FuryPO Team

Project FurySM Team


© 2009

The “main” Product Owner Problem

� Is the person on the team accountable to the business

and/or organization for the success of the team,

therefore…

� The ProductOwner has the right to be involved in every decision

the team makes, but an obligation not to micromanage;

� The ProductOwner has veto power at all times, but should control

the urge to use it; and

� The ScrumTeam has the obligation to give the ProductOwner all

the information needed to make good decisions.

� This causes interesting “power dynamics” that the Team/

ScrumMaster must manage…

� As a part of the Team, the Product Owner usually

� Acts as “Stakeholder Manager”

� Prioritizes Stories

� Does Release Planning

� Etc…



Danube Webinar 9

© 2009

Product Owner Responsibilities

Provide Vision, Goals, Direction

Drive the Team at a Sustainable Pace

Adapt and Release the Product


© 2009

Release

Review

& Adapt

Project

Start

Project

Visioning

Startup

Activities

Release

Planning

Sprint Sprint

Release

Sprint

Release

Planning

Sprint SprintCloseout

Activities

Release

Sprint

Release

&

Project

End

Review

& Adapt

Review

& Adapt

Review

& Adapt

Product Owner Responsibilities in Scrum

Product Vision

Budget

Product RoadMap

Product Backlog

Release Goal

Release Baseline

Release Strategy

Release Game Plan

Sprint Goal

Sprint Backlog


Drive Team at a Sustainable Pace




Danube Webinar 10

© 2009

Three Levels/Layers of Agility

� Tactical Agility (SM and Team)

� Inside the Sprint

� Explaining the “Whats” - Figuring out the “Hows”

� The SM helps the Team self-organize for this

� PO (person) is member of team, not PO

� Low-Level Strategic Agility (PO)

� On the Sprint Boundaries (and inside the Sprint)

� Modifying the Backlog

� Changing sprint goals without changing Release Goals

� Working with the BO and other Stakeholders

� Strategic Agility (BO and above)

� Modify the Release Goals and Product Roadmap

� Perhaps modify the Product Vision

� Done if Team isn’t meeting Release Goals…


© 2009

Product Owner’s Goal (agile or not)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 20 40 60 80 100

Earned Business Value

% of Team’s Budgeted Effort

"S-Shaped" Curve

architecturally

significant Must haves

Buffer,

Nice to haves,

Rework

critical mass point

Minimally releasable

� Move the Team along the S-Shaped curve to Release

� In “standard” PM, the plan is what makes this happen

� In agility, the PO being smart is what makes this happen



Danube Webinar 11

© 2009

Remember…

� The Product Owner is a member of a self-organizing scrum team

� There are three types of responsibilities on this team

� Development Responsibilities

� ScrumMaster Responsibilities

� ProductOwner Responsibilities

� The Scrum Team decides who does what, and each member of the

team is accountable to the Scrum Team to do it

� This means that the ProductOwner may not be the person who actually

does all the PO stuff…

� It’s based on the skills of the people on the team

� Scrum teams have people with skills, not people playing roles


© 2009







Danube Webinar 12

© 2009

Product Owner Challenge

� To make sure the project produces something of value

� That it represents the stakeholder’s needs

� This requires that the Product Owner understand what

the Stakeholders want 2 years from now (or the end)

� Product Vision and Goals

� Product Roadmap for Development

� Capabilities and Features

� Marketing, Sales support

� Etc

� That they provide a Release Plan/Strategy

� That they put together a Backlog for the team

� And make sure it gets populated with Stories


© 2009

Vision Examples

� Business Vision: I, SirJeff, want to get lots of new

customers for my new airline, Royal Catalina Air (so that

I can make a lot of money…)

� Product Vision: In order to get lots of new customers for

my airline, I want a website, RoyalCatalinaAir.com, that

will be as good as that of “real” airlines



Danube Webinar 13

© 2009

Definition/Overview of “Agile Analysis”


© 2009

Analysis: Product � Capability � Story

� Analysis is primarily about Decomposition

� Our Product decomposes into Capabilities

� Capabilities are implemented by doing stories

� But not all stories are capability-driven

� Our Project’s work can be seen as a collection of Stories

� But we’re only going to focus on the capability-driven ones

� Incremental Analysis is (basically):

� Find the Capabilities, validate them, then

� Find the Stories, and validate them

� Then we use the stories to drive development…

Product Capability Story



Danube Webinar 14

© 2009

Analysis Concept on One Slide

System

Capability

Minimum,

end-to-end,

Demonstrable,

Architecturally-Significant

Scenario

Backbone

Releasable

functionality

“Connective Tissue” stories


© 2009

Initial Backlog (Epics)

� Capabilities of CatAir Website

� [usecase] Buy an e-Ticket

� [usecase] Check Status of Flights

� [usecase] Manage Pilot Timesheets

� [usecase] Hotel and Car Reservations

� [usecase] Manage “Good Customer” Plan

� Other Stuff

� [enviro] Set up Team Room

� [enviro] Test Lab and Development Environment

� [maint] Support SouvSite.com



Danube Webinar 15

© 2009

Example: Stories for “Buy an e-ticket” Capability


� Continuous

Analysis

� As you move

along, you will

need to find new

stories “within” the

features

� What we see here

is the list of stories

for “Buy an e-

Ticket” that were

prepared and/or

implemented in this

release

[usecase] Buy an e-Ticket Fd Dn Size

[backbone] Get List of Flights from CUTLASS (ugly interface) 0 1 L

[backbone] Capture Itinerary Information 0 2 L

[backbone] Capture Passenger Information 0 2 L

[backbone] Reserve Flight in CUTLASS 0 2 L

[alt] Modify CUTLASS to Understand When Flight is Full (note: was awful!) 2 3 L

[analysis] Analysis Meeting with SirJeff 1 3 S

[backbone] Pick One Flight and Pay for It (note: stubbed out actual payment) 0 3 L

[alt] Handle Round Trip Flights (ugly Interface) 0 3 L

[beefup] Hook Up Actual Visa/MasterCard Processing Widget (note: was a PITA) 3 4 L

[backbone] Issue email Confirmation to Customer 0 4 M

[interface] Improve Interface for buying e-ticket 3 4 M

[beefup] Close Reservations when Plane is Full (note: turned out to be easy) 0 4 L

[alt] Add Payment with PayPal (note: really straightforward) 3 4 M

[alt] Reserve Flight to Pay upon arrival at Airport 0 4 M

[alt] Handle multiple-Passenger Parties 0 5 L

[interface] Web Interface for Adding/Modifying Flight Info 3 5 L

[beefup] Get Luggage Info, including Scuba Tanks 3 5 L

[analysis] Exploratory Testing to "See What's Left" for Buy an e-Ticket 4 5 S

[spt] Make sure SirJeff’s Marketing materials have correct information 2 5 S

[bug] Fix Bug in Luggage Weight Calculations 5 5 S

[bug] Fix Small List of Bugs found in Exploratory Testing 5 6 M

[alt] Pay with AMEX 3 M

[alt] Bring Pet on Board 5 M

[beefup] Special Needs (wheelchair, etc) 5 S

[alt] Select Seat online 3 M

[alt] Pay with Coupon 3 M

[beefup] Seat Belt Extender Needed for 'large' Passenger 3 S

[beefup] Special Meals 5 S

[alt] Change Seat online 3 M

[alt] Comfort Seat for 'really large' Passenger 5 S


























































































































































































































© 2009

Release Planning



Danube Webinar 16

© 2009

What is an Agile Release Plan?

� SirJeff wants us to release V1 of the website in 3 months

(14 weeks). He wants to know what he can tell his

marketing and sales folks will be there. In other words, we

need a Release Plan

� An Agile Release Plan is actually a Strategy

� How Many StoryPoints (SPs) do we have to play with, and how

many do we allocate (baseline) to individual features, goals,

capabilities? (budget plus shopping list plus strategy)

� Relying on agility as we go in order to optimize the Business Value

(BV) that is produced (what happens when we go to store)

� NOT a series of Sprint Plans

� In fact, we don’t want all the stories – lean principle

� Will do analysis as we go, in parallel, and along with

development


© 2009

What’s Going On

� Have a team

� Transitioning from SouvSite development

� Half the team for the first 2 sprints

� Whole team from then on

� Velocity of 60 SPs/Sprint

� Expense is 400 Hours/Sprint for the team

� Have a client, Royal Catalina Airlines (RCA)

� Royal Catalina Airlines is owned by Sir Geoffrey Smithers (SirJeff)

who made a fortune writing software in the Silicon Valley before

buying a plane and ferrying tourists up and down the California

Coast

� He is now buying 4 more planes, hiring pilots, crews, etc, and

wants a web site, RoyalCatalinaAir.com. We’re writing it for him…



Danube Webinar 17

© 2009

Baseline Total Capacity Calculations (budget)

� We have half the team for the first

two sprints

� We have a Transition sprint, as we

bring the rest of team over

� And then we have four ”full” sprints

� Joe’s on a Honeymoon sprints 5-6

� This is a total of 335 SPs as our

baseline SP budget

� And we “spend” 2820 hours to do it

� 60 hours/person/sprint

Sprint 1 2 3 4 5 6 7 Total

Hours 240 240 480 480 468 432 480 2820

SPs 30 30 45 60 58 52 60 335


© 2009

Goals and Baselines (shopping list)

� After working with SirJeff and our Team for 2-3 days, we come

up with the basics of our Release Plan, as follows…

Capability/Item BV Baseline

Buy an e-Ticket 80% 108SP

Investigate CUTLASS interface/capabilities 10SP

Investigate the basics of Pilot Timesheets 10% 20SP

Check Status of Flights 10% 40SP

SouvSite Maintenance (before Release Sprint) 23SP

Chores (before Release Sprint) 79SP

Release Sprint (includes SouvSite Maint and Chores) 60SP

Total 100% 335SP

risky



Danube Webinar 18

© 2009 Product Owner by Dan Rawsthorne 35

And we Come Up With a Baseline Game Plan

� Note that we decomposed the Release Sprint into pieces, too, in

order to manage “Release Activities”

© 2009







Danube Webinar 19

© 2009

Sprint/Iteration

DailyStandup

Sprint/Iteration

Sprint Planning Meeting

Reports/

Metrics/

Impediments

Backlog

Sprint

Backlog

Increment

of Product

ResultsSprint Review

Retrospective

Sprint

Planning


© 2009

Purpose of Sprint Planning

� To come to an “agreement” between the Product

Owner and the team

� To determine which stories will be worked on in the

sprint

� To specify in more detail what each story means so

that it can be estimated and so that “scope creep” will

be avoided during the sprint

� This becomes the team’s “contract” for the sprint

� For the team to decompose the stories to tasks

� The PO is normally not involved (as the PO)

� But could be involved as a Team Member



Danube Webinar 20

© 2009

Commitment Driven Planning Script

1. Product Owner (with assistance from Team) prioritizes stories in

Backlog

2. Team with Product Owner – Add “Agreement” section to highest-

priority story remaining on your list

3. Team w/o Product Owner – Break-Out the Story into Tasks

4. Team w/o Product Owner – Decide if you can get that story “done” in

the Sprint (“thumbs up” from team)

� If No, Stop and draw Sprint Backlog line above the story you just Tasked out, but

can’t commit to…

� Note: you can try moving another (smaller) story above the line and going

back to step 2

� If Yes, Ask the team if it’s “full”

� If Yes, stop

� If No, continue at step 2 with next story


© 2009

Commit-Driven Planning “in action”

Stories TasksIn ProgressTasks

Sprin

t Backlog

Completed



Danube Webinar 21

© 2009

Stories


© 2009

Stories

� Requests for Valuable stuff... � “… are a promise for a future conversation” - Ron Jeffries (from Alistair

Cockburn)

� Have “Doneness” criteria

� Have Value (not all have Business Value)

� Have Story Size – I use “t-shirt sizes”, S/M/L, with value 2/4/8

� Have Tasks to get them “done”

� Have Effort (estimated and actual), usually at Task level

� Different from Requirements:� Requirement: “here’s what I want, go do it...”

� Story: “here’s what I want, let’s talk...”



Danube Webinar 22

© 2009

Acceptance Criteria (definition of “done”)


© 2009

Iron Triangle and “Doneness”

EffortStory Done List

----

Tests to Pass

Time Boxes

--

Inspections

Process Reqts

� Agile Planning is actually about balancing effort, scope, and technical debt

� The expected scope and debt is seldom documented in detail, but there is a virtual list (which I often like to make explicit)

� DoneList (acceptance criteria) has two parts� Scope Side, usually defined by tests, time boxes, etc

� Debt Side, usually defined by inspections, process steps, etc

� The DoneLists have different qualities for different types of stories (storyotypes), and lead to specific tasks to get the DoneList completed”

balance



Danube Webinar 23

© 2009

Sample Development Story

Get List of Flights from CUTLASSSize: 8 SPs Type: [backbone]

As a <flyer> I want <to have a list of flights that matches my itinerary> so that <I can choose one that works for me>

General: - Joe is the expert on CUTLASS- Simplifying Assumptions: One Way, Single Leg, No Seat Selection, Single Passenger, Full Fare, No Luggage …

Acceptance:- Pass in an itinerary and get a list of Flights back

Doneness:� Review Architectural Decisions with Team� Design Review� Review Functional Test Strategy� Review Unit Tests� Verify Tests passing on Development Machine � Code Review� Functional Tests Written� Verify Tests passing on Integration Box� Add Tests to Regression Test Suite

Architecture and Design

32 hrs

Write Functional Tests

12 hrs

Code and Unit Test

80 hrs

Tasks

© 2009

Doing the Work



Danube Webinar 24

© 2009

Sample Task Board


© 2009

Sample Task Board (in tool)



Danube Webinar 25

© 2009

PO/Analysts

Team Swarm

Coders

Testers

Stakeholders

To the

BacklogTo The

Product


© 2009

Technical Debt



Danube Webinar 26

© 2009

What is Technical Debt?

Story Points

Time

22 SP Dead Legacy, Velocity = 0

no


� I like to think of Technical Debt as “Viscosity of Code”

� What makes the code hard to work with

� “Walk in the Park”, vs “Slog in the Swamp”

© 2009

Avoid Technical Debt

� Development teams must curb over-optimism in

assessing availability and capacity

� Management redirects attention from applying

pressure to removing organizational impediments

to progress

� Product Owners understand the iron triangle,

ownership of risks, and impact of cutting quality

� ScrumMaster must prevent demonstration of any

work that is not “done.”

� Retrospective Issue: “anyone produce any code

they’re not particularly proud of?”



Danube Webinar 27

© 2009






© 2009

Sprint Review



Danube Webinar 28

© 2009

Sprint Review

� The primary “inspect and adapt” mechanism

between the team and stakeholders in scrum is

the Sprint Review

� This Review is the PO’s meeting. In it, the PO is

showing the Stakeholders what his/her Team has

produced for them, and getting feedback

� Show the Stakeholders what they need to see so that they

can assess whether or not the team is going in the right

direction

� Show the Stakeholders what the Team needs them to see so

that the Team knows they are going in the right

direction


© 2009

Discuss with Stakeholders

� The Team Does the Demo

� The Team does the actual work of showing the

Stakeholders that “needs to be shown”

� The Team interacts with the Stakeholders, facilitated

by the ScrumMaster and Product Owner

� PO leads discussion with Stakeholders (often

facilitated by ScrumMaster

� Are we Releasable?

� What do you want to do next?

� What should the next Sprint’s Goal(s) be?

� What do you want to see at the next Sprint

Review?



Danube Webinar 29

© 2009

“Hard Core” Metrics for an Agile Project


© 2009

How the Release Actually Played Out


Hours 253 233 495 530 467 445 498 2921

SPs 26 32 42 54 66 52 54 326



Danube Webinar 30

© 2009

Release Burnup

Correction

In Sprint 3

� We are delivering

capabilities and Stories

� But what we are

managing is (largely)

StoryPoints

� The BurnUp graph

shows our production of

StoryPoints

� It shows our SP

velocity graphically

� It shows how many

SPs we have “to go”

� It shows our inventory

of SPs that are “ready

to go”

� And it’s easy to

calculate


© 2009

CPI and SPI for SirJeff

� This graph shows our

SPI and CPI as we move

through the sprints

� The values are calculated

cumulatively, not one

sprint at a time


Hrs (B) 240 240 480 480 468 432 480 2820

SPs (B) 30 30 45 60 58 52 60 335

Hrs (A) 253 233 495 530 467 445 498 2921

SPs (A) 26 32 42 54 66 52 54 326



Danube Webinar 31

© 2009

Earned Business Value Graphs

Correction

In Sprint 3


© 2009

Summary



Danube Webinar 32

© 2009

So, to Summarize…

� The Product Owner is the Team Member who is the

"single wringable neck”

� The Organization “owns” this, not us

� What the Product Owner does on the team is based on his

or her skills and the needs of the team

� This is a self-organizing team containing people with skills, not

people playing roles

� But, some of the PO responsibilities are best done by the PO

� All Product Owners are different


© 2009

Discussion



Danube Webinar 33

© 2009

Any Questions?


© 2009

Thank You Very Much!


Rawsthorne | Who is your PO

Technology

product owner po

scrum teamthe product

product owner1292009why

cycles product

product owners

emphasis minethe product

scrum process

scrum way