The document outlines the role and responsibilities of an Agile Product Owner, emphasizing the significance of making profitable software development decisions, managing the product backlog, and prioritizing user stories based on expected ROI. It addresses challenges faced by Product Owners and illustrates various planning waves for product, release, feature, and story levels while highlighting the importance of incremental funding methodology and understanding market needs. Additionally, it discusses strategies for prioritizing features and maximizing return on investment through effective release planning.

1. Agile Product Owner

2. The Goal
What is the goal of software development?
Hint: It is not to produce working code
It is to make a profit

3. 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

4. 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
releases
based upon expected ROI
Accepts (or rejects) User Stories
on behalf of the Customer

5. 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

6. 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.

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

8. Product over Project

9. Always
7%
Often
13%
Sometimes
16%
Rarely
19%
Never
45%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
Often or Always
Used: 20%
Rarely or Never
Used: 64%

10. Plan Design Build Test
Release
Bug Fix

11. exemplify
validate
release
innovate
Inspect & Adapt

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

13. Plan Design Build Test
Release
Bug Fix
start finish
project timeline
Point where finding defects
least desired.

14. v2.0 v2.1 V3.0
Change
v2.15
Change Change Change
v2.2

15. Value over Date over Scope

16. 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

17. 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.

18. Rolling Wave Planning
Product
Larger ideas are further
away and detailed out
as the date nears.
6-12 months
ahead
Release 3-6 months
ahead
Feature
2-4
weeks
ahead

19. 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

20. Product Planning Wave
 Scope - Annually
What 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

21. 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/hour
2. …
Tradeoff Matrix
Scope
Resources
Schedule
Quality
Fixed Firm Flexible
√
√
√
√
Major Milestones
Xyz features xxx
Abc features xxx
Metrics and ROI

22. 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

23. 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

24. 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

25. 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

26. Multi-year Vision
The Waves Combined
Yearly Product
Quarterly Release
Monthly Feature
Sprint Story
Daily Work

27. Multi-Level
Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3

28. Relative Sizing
1 2 3
5
8
13
20
40 100

29. The rate of change in displacement with
respect to time.
It has both magnitude and direction.
Velocity Formula

30. How difficult is the journey?
8 minutes
12 minutes
1 mile

31. Velocity
0
50
100
150
200
250
300
350
400
1 2 3 4 5 6 7 8 9 10
Actual
Best
W orst
Last
Average
0
5
10
15
20
25
30
35
40
1 2 3 4 5 6 7 8 9 10
Actual
Best
W orst
Last
Average

32. Cone of Uncertainty

33. A story point takeoff chart
12
27
58
76
99
117
132
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
170
180
190
200
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Points

34. What can I have?
Desired
release date
1 July
Today s Date 12 February
Number of
sprints
10 (2 week
length)
Worst 12
Average 22
Last 26
Best 34

35. Last (26)
When can I have it?
Total Points 150
Today s Date 12 February
23 AprilBest (34)
7 May
Average (22) 21 May
Worst (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

36. Releases cover multiple
iterations
4
4
3
4
2
1
3
V = 21
3
2
1
54
3 3
V = 21

37. 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

38. ready to deliver

39. Planning
Analysis
Design
Coding
Testing
Performance
User Acceptance
Staging
Live

40. May require a Release Sprint
AKA “hardening”
Fit and finish
Shrink Wrap
Intensive customer involvement
Suggested for immature Sprint teams

41. Release
Planning
R1 R2 R3

42. Incremental Releases
Users and Stakeholders Will Love
How to deliver functionally complete, valuable, incremental
releases
Jeff Patton
ThoughtWorks
jpatton@thoughtworks.com
Copyright is held by the author/owner(s).
OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA.
2006 ACM 06/0010.

43. 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

44. 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

45. 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

46. Using Our Task Model to Identify Features
that Span Our Business Process
The 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
necessity
Activity 1
smallest list of tasks
to support users =
smallest span

47. 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
optionality
necessary
less
optional
more
optional
activity 1 activity 2 activity 3 activity 4
first release
second release
third release

48. This Product Thickening Strategy
Slowly Brings The Product Into Focus
Just 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.

49. 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

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

51. 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.

52. ReturnonRevenue
Months to
complete
1
1
1
2
1
3
Release 2
Release 1
Release 3
1
4
1
5
1
6

53. 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

54. Features are Supported By
Architectural Elements

55. 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

56. Prioritizing Features
High
High
Low
Low
Risk
Value
1
23
X

57. Force-rank Features on a
Product Backlog
Deploy 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

58. 4 Release Strategies for the Same
Product Features
Return On Investment
(2,000)
(1,000)
-
1,000
2,000
3,000
4,000
5,000
6,000
1 4 7 10 13 16 19 22
Month
Thousandsof$s
Single Release
12 months
total cost: $1.3 M
total 2 year return: $3.6 M
net 2 year return: $2.3 M
Cash Investment: $1.3 M
Internal Rate of Return: 9.1%
Return On Investment
(2,000)
(1,000)
-
1,000
2,000
3,000
4,000
5,000
6,000
1 4 7 10 13 16 19 22
Month
Thousandsof$s
Semi Annual Release
6 months increment
total cost: $1.4 M
total 2 year return: $4.8 M
net 2 year return: $3.4 M
Cash Investment: $.7 M
Internal Rate of Return: 15.7%
Return On Investment
(2,000)
(1,000)
-
1,000
2,000
3,000
4,000
5,000
6,000
1 4 7 10 13 16 19 22
Month
Thousandsof$s
Quarterly Release
3 months increment
total cost: $1.6 M
total 2 year return: $5.3 M
net 2 year return: $3.7 M
Cash Investment: $.44 M
Internal Rate of Return: 19.1%
Return On Investment
(2,000)
(1,000)
-
1,000
2,000
3,000
4,000
5,000
6,000
1 4 7 10 13 16 19 22
Month
Thousandsof$s
Quarterly Release – drop the
last release
3 months increment
total cost: $1.2 M
total 2 year return: $4.9 M
net 2 year return: $3.7 M
Cash Investment: $.44 M
Internal Rate of Return: 20.4%
Return On Investment
(2,000)
(1,000)
-
1,000
2,000
3,000
4,000
5,000
6,000
1 4 7 10 13 16 19 22
Month
Thousandsof$s
Quarterly Release – continue
with 5th release
3 months increment
total cost: $2 M
total 2 year return: $6.2 M
net 2 year return: $4.24 M
Cash Investment: $.44 M
Internal Rate of Return: 19.0%
Source: Jeff Patton
Incremental 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 return
Features begin earning money 1
month after release
Each month of development costs
$100K
Each release costs $100K

59. 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

60. Scaling the Product Owner
Product
Owners
Product Line
Owners
Chief Product
Owner

61. Who has the „D‟?