Rawsthorne | Who is your PO

Dan Rawsthorne: Product Owner 12/9/2009

Dan Rawsthorne
Certified Scrum Trainer
Senior Coach
Danube Technologies, Inc.
dan@danube.com

Agile Days ‘09, Moscow
December 9, 2009

Product Owner
The Secret of Success

© 2009

Topics to Cover

How Scrum Works
Who/What is the Product Owner (PO)?
Responsibilities of the PO
Summary
Discussion

© 2009 Product Owner by Dan Rawsthorne 2

Danube Webinar 1


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


How Scrum Works


Danube Webinar 2


Mechanics of Scrum: Flow Each Sprint

Reports/
Daily Metrics/
Standup
Impediments

Sprint/
Iteration

Sprint
Planning Increment
Sprint of Work
Backlog

Backlog Sprint Review
Retrospective Results


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 3


Who/What is the Product Owner?


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 4


The Basic Scrum Engine (Scrum Team)

Product Owner is the Key
As a Person
Single-Wringable Neck
Stakeholders Decides on Releasability
Business As a Role
Owner
Stakeholder Management
Vision, Goals, and Features
SME
Release Planning
SME Scrum Product
Master Owner Drives the Team
Understands ROI
Prioritizes Stories
Acts as SME, or brings
SME SME them in
Drive the Team


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 5


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)


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…

“Product H-12” These people
Office Management
SMEs
Are POs. It’s not
Staff Team A choice – it’s a
Product Manager: Hugh
definition

“Project Gold” “Project Silver” “Project Fury”
Management Development Management
Team Team Team
Project Manager: Gerry Project Manager : Susan Project Manager: Fiona
Team Lead: Stan

“Pirates” “Warriors” “Lions” “Tigers” “Bears”
DevTeam DevTeam DevTeam DevTeam DevTeam
Team Lead: Pete Team Lead: Wendi Team Lead: Lars Team Lead: Tanvi Team Lead: Bhanu


Danube Webinar 6


Managing with Scrum

Organizational Teams
Project Management Team “Project Gold” Project Gold
Dev Teams Management PO Team
Team
Scrum Teams (potentially) Project Manager: Gerry

Project Management Team
“Pirates” “Warriors”
Dev Teams DevTeam DevTeam
Team Lead: Pete Team Lead: Wendi
Product Owner Teams (virtual)

“Product H-12”
Office Management Product H-12 Communicate
SMEs PO Team
Staff Team Cooperate
Product Manager: Hugh Coordinate

“Project Gold” “Project Silver” “Project Fury”
Management Development Management
Team Team Team
Project Manager: Gerry Project Manager : Susan Project Manager: Fiona
Team Lead: Stan


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

Mgmt Unallocated
“Project Fury” Backlog Backlog
Management
Team
Project Manager: Fiona

Team Team Team
“Tigers” Backlog “Bears” Backlog “Lions” Backlog
DevTeam DevTeam DevTeam
Team Lead: Tanvi Team Lead: Bhanu Team Lead: Lars

The Team’s Backlog may only consist of the Sprint Backlog, or
could be more of it…


Danube Webinar 7


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

Project Fury “Project Fury” Project Fury
SM Team Management PO Team
Team
Project Manager: Fiona
ScrumMaster: Rob

“Tigers” “Bears” “Lions”
DevTeam DevTeam DevTeam
Team Lead: Tanvi Team Lead: Bhanu Team Lead: Lars
ScrumMaster: Joe ScrumMaster: Pavel ScrumMaster: Martin


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 8


Product Owner Responsibilities

Provide Vision, Goals, Direction
Drive the Team at a Sustainable Pace
Adapt and Release the Product


Product Owner Responsibilities in Scrum

Review Review Review Review
& Adapt & Adapt & Adapt & Adapt

Startup Release Release
Project Activities Sprint Sprint
Sprint Sprint Sprint Sprint
Visioning Release Release Closeout
Planning Planning Activities

Project Release Release
Start &
Project
Product Vision Release Goal End
Budget Release Baseline
Product RoadMap Release Strategy Sprint Goal
Product Backlog Release Game Plan Sprint Backlog

Provide Vision, Goals, Direction Adapt and Release the Product

Drive Team at a Sustainable Pace


Danube Webinar 9


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…

Product Owner’s Goal (agile or not)

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

"S-Shaped" Curve
1
critical mass point
0.9 Minimally releasable
0.8
Earned Business Value

Buffer,
0.7 Nice to haves,
0.6 Rework
0.5
architecturally
0.4 significant Must haves
0.3
0.2
0.1
0
0 20 40 60 80 100
% of Team’s Budgeted Effort


Danube Webinar 10


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





Danube Webinar 11


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


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 12


Definition/Overview of “Agile Analysis”


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 13


Analysis Concept on One Slide
“Connective Tissue” stories

Backbone

Capability

Minimum, Releasable
System end-to-end, functionality
Demonstrable,
Architecturally-Significant
Scenario

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 14


Example: Stories for “Buy an e-ticket” Capability
[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 Continuous
[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] Analysis Meeting with SirJeff 1 3 S
[backbone] Pick One Flight and Pay for It (note: stubbed out actual payment) 0 3 L As you move
[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
along, you will
[backbone] Issue email Confirmation to Customer 0 4 M need to find new
[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 stories “within” the
[alt] Add Payment with PayPal (note: really straightforward) 3 4 M
[alt] Reserve Flight to Pay upon arrival at Airport 0 4 M
features
[alt] Handle multiple-Passenger Parties 0 5 L
[interface] Web Interface for Adding/Modifying Flight Info 3 5 L
What we see here
[beefup] Get Luggage Info, including Scuba Tanks 3 5 L is the list of stories
[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 for “Buy an e-
[bug] Fix Bug in Luggage Weight Calculations 5 5 S
[bug] Fix Small List of Bugs found in Exploratory Testing 5 6 M
Ticket” that were
[alt] Pay with AMEX 3 M prepared and/or
[alt] Bring Pet on Board 5 M
[beefup] Special Needs (wheelchair, etc) 5 S implemented in this
[alt] Select Seat online
[alt] Pay with Coupon
3
3
M
M
release
[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


Release Planning


Danube Webinar 15


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


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 16


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


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…
risky
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


Danube Webinar 17


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”





Danube Webinar 18


Sprint Planning Meeting

Reports/
Daily
Standup Metrics/
Impediments

Sprint/
Iteration

Sprint
Planning
Increment
Sprint of Product
Backlog

Sprint Review
Retrospective Results
Backlog


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 19


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


Commit-Driven Planning “in action”

Stories Tasks Tasks Completed
In Progress
Sprint Backlog


Danube Webinar 20


Stories


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 21


Acceptance Criteria (definition of “done”)


Iron Triangle and “Doneness”

Effort
Story Done List
----
Tests to Pass
balance 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”


Danube Webinar 22


Sample Development Story

Get List of Flights from CUTLASS Tasks
Size: 8 SPs Type: [backbone]

As a <flyer> I want <to have a list of
flights that matches my itinerary> so that
Architecture
<I can choose one that works for me> and Design
General: 32 hrs
- Joe is the expert on CUTLASS
- Simplifying Assumptions: One Way, Single Leg, No
Seat Selection, Single Passenger, Full Fare, No
Luggage … Write Functional
Acceptance:
- Pass in an itinerary and get a list of Flights back
Tests
Doneness:
Review Architectural Decisions with Team
12 hrs
Design Review
Review Functional Test Strategy
Review Unit Tests
Verify Tests passing on Development Machine
Code and Unit
Code Review Test
Functional Tests Written
Verify Tests passing on Integration Box 80 hrs
Add Tests to Regression Test Suite

© 2009

Doing the Work


Danube Webinar 23


Sample Task Board


Sample Task Board (in tool)


Danube Webinar 24


Team Swarm

Stakeholders

PO/Analysts Testers

To the To The
Backlog Product

Coders

Technical Debt


Danube Webinar 25


What is Technical Debt?

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”

22 SP Dead Legacy, Velocity = 0
Story Points

Time
no

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 26





Sprint Review


Danube Webinar 27


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

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 28


“Hard Core” Metrics for an Agile Project


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 29


Release Burnup

We are delivering
capabilities and Stories
But what we are
managing is (largely)
StoryPoints
Correction The BurnUp graph
In Sprint 3 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


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 30


Earned Business Value Graphs

Correction
In Sprint 3


Summary


Danube Webinar 31


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


Discussion


Danube Webinar 32


Any Questions?


Thank You Very Much!


Danube Webinar 33

Rawsthorne | Who is your PO

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (7)

Similar a Rawsthorne | Who is your PO

Similar a Rawsthorne | Who is your PO (20)

Más de Nikita Filippov

Más de Nikita Filippov (20)

Último

Último (20)

Rawsthorne | Who is your PO