agile product owner
DESCRIPTION
Concepts from Jeff Patton, Marty Cagan, Software by Numbers, David Anderson, Feature Driven Development being taught while at Yahoo.TRANSCRIPT
Agile Product Owner
The Goal
What is the goal of software development?
Hint: It is not to produce working code
It is to make a profit
Product Owner Role
How would you describe it?
Define a successful product.
Sets the product direction at all levels
Represents the customer and business domain on the team
Represents the product to the customer
CEO of the product
Manages the Product Backlog
Product Owner Role
Responsible for market, business case, and competitive analysis
Captures most of the User Stories and their Acceptance Criteria
Prioritizes in a stack rank the User Stories for releasesbased upon expected ROI
Accepts (or rejects) User Stories on behalf of the Customer
Product Owner Role
Responsible for ROI, Cost and Net Profit
Higher operating expense in longer release cycles
Scope impacts business value in Expected ROI
Chooses the mix of features for releases
The most value
in the smallest scope
within the shortest time
Product Owner Challenges
1.Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself.
2.Resisting the temptation to add more work
3.Being willing to make hard choices during a planning meeting.
4.Balancing the interests of competing stakeholders.
Pig or a chicken?
Originally the Product Owner role was considered a chicken role. That’s to say it was a role that required no commitment to the Sprint goals. This has changed over the past as the product owner role has been identified as a key to success or failure of a project.
Product over Project
Always7%
Often13%
Sometimes16%
Rarely19%
Never45%
Standish Group study reported at XP2002 by Jim Johnson, Chairman
Often or Always Used: 20%
Rarely or NeverUsed: 64%
Plan Design Build Test
Release
Bug Fix
exemplify
validate
release
innovate
Inspect & Adapt
v2.0 v2.1 v2.2 v2.3 v2.4
Plan Design Build Test
Release
Bug Fix
ChangeRequest
start finishproject timeline
Point where finding defects least desired.
v2.0 v2.1 V3.0
Change
v2.15
Change Change Change
v2.2
Value over Date over Scope
Value Rolls Up
Suite - Interrelated products and platforms
Product - Satisfies a market need
Release - Deployed feature set proving value
Feature - Minimal and marketable set of Stories
User Story - Smallest block of customer value
Steering the Planning
Driving as a Metaphor
Where are we heading?
Continuously adjust steering based on feedback from the road.
Make turns down roads to reach the destination, get by obstacles, or when changing course.
Rolling Wave Planning
Product
Larger ideas are further away and detailed out as the date nears.
6-12 monthsahead
Release 3-6 monthsahead
Feature2-4 weeksahead
Vision Planning Wave
Scope - For Multiple years Are the Vision and Mission statements fresh? Are the objectives in line with these statements?
Updated - Every year
Results of plan Vision and mission shared internal and external Status on objectives updated and communicated
Product Planning Wave
Scope - AnnuallyWhat objectives will be addressed?What is the compelling statement of need?
Updated - Each Quarter
Results of plan Establish time-to-market commitments Product roadmap One-pager for each product
Product One Pager
Elevator Statement
For…who…that…Unlike…
Customer Attributes
1. People who work in …2. Those who need a …3. …
Feature / Ability to…
1. Share content with…2. Personalized ads on…3. …
Metrics:
Sign-ups xxx
Customer Benefits
1. More accurate …2. Better customer service …3. …
Performance Attributes
1. 3000 hits/hour2. …
Tradeoff Matrix
Scope
Resources
Schedule
Quality
Fixed Firm Flexible
√
√
√√
Major Milestones
Xyz features xxxAbc features xxx
Metrics and ROI
Release Planning Wave
Scope - Quarterly What needs to be released next? What is the size of the release?
Updated - Monthly Re-evaluate plan, make adjustments, notify stakeholders Derive duration based on size of Stories in release
Results of Plan People organize in to feature teams Minimal features to market established Update schedule of release window
Collecting features into releases for scheduling is your primary planning tool
Feature Planning Wave
• Scope - Monthly• What User Stories comprise this feature?• How do we know when the feature is done?
Updated - Weekly Revisit the backlog and keep highest-valued User Stories
at the top.
Results of plan Break down a feature into stories Write initial acceptance criteria for stories Team estimates size of stories to derive duration Inestimable stories are identified as a ‘spike’ Logically group features in to a theme if needed Prioritize stories in the team’s Product Backlog
Story Planning Wave
• Scope - Every Sprint• What tasks are needed to deliver this story?• How do we know when the story is done?
Updated - Every day Ensure tacit knowledge of high-rank user stories is strong Stories updated to reflect tasks needed
Results of plan Break down a story into tasks All tasks needed for delivery identified Story can be delivered as working software
Work Planning Wave
Scope - Daily• What did I finish yesterday?• What am I doing today?• What is in my way of finishing?
Updated - As tasks finish• Update work board to reflect what is being worked on• Ensure tasks prove out acceptance criteria
• Results of plan• Identify bottlenecks to work-in-progress• Swarm on tasks to complete User Stories
Multi-year Vision
The Waves Combined
Yearly Product
Quarterly Release
Monthly Feature
Sprint Story
Daily Work
Multi-Level Planning
Product Vision
Roadmap
Release Plan
Sprint Plan
Daily Plan
Q1 Q2 Q3
R1 R2 R3
Relative Sizing
1 2 3 58
13
20
40 100
The rate of change in displacement with respect to time.
It has both magnitude and direction.
Velocity Formula
How difficult is the journey?
8 minutes
12 minutes
1 mile
Velocity
Cone of Uncertainty
A story point takeoff chartP
oint
s
What can I have?Desired
release date1 July
Today’s Date 12 February
Number of sprints
10 (2 week length)
Worst 12
Average 22
Will have above
Wont have below
10x12=120
10x34=340Last 26
Best 34
Very likely to have
10x22=220Pretty likely to have10x26=260
Last (26)
When can I have it?
Total Points 150Today’s Date 12 February
23 April Best (34)7 May
Average (22) 21 MayWorst (12) 30 June
150/12=12.5
150/22=6.8
150/26=5.7
150/34=4.4
2/12 4/23 5/21 6/30
Releases cover multiple iterations
44
3
4
2
1
3
V = 21
32
1
54
3 3
V = 21
Story A
4
Story B
4
Story C
3
Story D
3
Story E
2
Story F
4
Story G
3
Story H
2
Story I
3
Story J
3
Story K
4
Story L
1
Iteration 1
Iteration 2
ready to deliver
Planning
Analysis
Design
Coding
TestingPerformanc
e User Acceptance
Staging
Live
May require a Release SprintAKA “hardening”
Fit and finish
Shrink Wrap
Intensive customer involvement
Suggested for immature Sprint teams
Release Planning
R1 R2 R3
Incremental Releases Users and Stakeholders Will Love
How to deliver functionally complete, valuable, incremental releases
Jeff [email protected] is held by the author/owner(s).OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA.2006 ACM 06/0010.
Software By Numbers & Project Portfolios
Software by Numbers [Denne & Cleland-Huang] describes Incremental Funding Methodology [IFM]
Goal to reduce necessary cash outlay
Make projects self-funding
Increase return on investment
SBN Tools:
http://dactyl.cti.depaul.edu/ifm/default.htm
SBN introduces the concept of Minimal Marketable Feature – MMF - the smallest sized feature that would have marketable value
SBN simple financial models provide guidance on evaluating multiple projects in a portfolio
A Lot Can And Does Go Wrong During Design And Development
process risks
delays & cut scope
scope additions
scope subtractions
design not built as described
risks from outside the process
political
financial
loss of key talent
A Lot Can And Does Go Wrong At Release Time
design off target – doesn’t meet user or business goals
product made unusable by poor performing technical architecture
ROI estimates were big fat lies
Using Our Task Model to Identify Features that Span Our Business ProcessThe Task Model we’ve built identifies the major activities and tasks that span the business functionality
A successful software release must support all necessary activities in the business process
This type of task model is referred to as a Span Plan since it helps identify the spans of functionality
Task 1 Task 2 Task 3 Task 4 Task 5
Task 6 Task 7
time
nece
ssity
Activity 1
smallest list of tasks to support users = smallest span
Identify Releases In a Span Plan By Slicing Horizontally
Choose coherent groups of features that consider the span of business functionality and user activities.
Support all necessary activities with the first release
Improve activity support with subsequent releases
time
optio
nalit
y
necessary
lessoptional
moreoptional
activity 1 activity 2 activity 3 activity 4
first release
second release
third release
This Product Thickening Strategy Slowly Brings The Product Into FocusJust as an artist envisions an entire painting by starting with a
sketch or an under-painting and slowly building up detail, apply the same strategy to “thicken” the product from simple necessities through to full featured product.
Project Success is Not Product Success
Placing focus on finishing all scope on time and in budget may equate to project success
Finishing all intended scope on time, and under budget does not guarantee product use or quality of use
Focus on effective support of user tasks
Focus on achieving stakeholder and user goals
Focus on getting product into use to begin earning revenue for its business stakeholders
Agile development may be characterized by short cycles of planning and design, building, and testing and evaluation.--Jeff Patton
Minimal Marketable Feature
A A feature is minimal because if it was any smaller, it would not be marketable.
It is marketable because when released to production, customers will use it.
Retu
rn o
n R
even
ue
Months to complete 1
112
13
Release 2
Release 1
Release 3
14
15
16
Different Types of Features
Table Stakes
Parity to the competition
Minimum needed to be in the game
Delighter
Differentiates you from the competition
Excites the customer
Spoiler
Competitor’s advantage
Raises the bar for parity
Pain Reliever
Reduces Cost
Improves the margin
Features are Supported By Architectural Elements
From Themes to Features
5
13
3
13
8
5
8
8
5
2
13
8
5
8
13
2
20
5
13
8
5
13
20
8
5
13
3
13
8
5
8
852
13
8
5 8
13
2 20
5
13
8
513
20
8
Prioritizing Features
High
High
Low
Low
Ris
k
Value
1
23
X
Force-rank Features on a Product BacklogDeploy highest value
Maximize throughput
Maximize ROI
De-scope lowest value
When date is fixed
Adjust to competition
Adjust to emerging features
Focus the effort to get Stories done/shippable
KISS
Swarm
4 Release Strategies for the Same Product Features
Single Release12 months
total cost: $1.3 Mtotal 2 year return: $3.6 Mnet 2 year return: $2.3 MCash Investment: $1.3 M
Internal Rate of Return: 9.1%
Semi Annual Release6 months increment
total cost: $1.4 Mtotal 2 year return: $4.8 Mnet 2 year return: $3.4 MCash Investment: $.7 M
Internal Rate of Return: 15.7%
Quarterly Release3 months increment
total cost: $1.6 Mtotal 2 year return: $5.3 Mnet 2 year return: $3.7 MCash Investment: $.44 M
Internal Rate of Return: 19.1%
Quarterly Release – drop the last release3 months increment
total cost: $1.2 Mtotal 2 year return: $4.9 Mnet 2 year return: $3.7 MCash Investment: $.44 M
Internal Rate of Return: 20.4%
Quarterly Release – continue with 5th release3 months increment
total cost: $2 Mtotal 2 year return: $6.2 Mnet 2 year return: $4.24 MCash Investment: $.44 M
Internal Rate of Return: 19.0%Source: Jeff PattonIncremental Releases Users and Stakeholders Will Love
All features delivered and in use earn $300K monthly
About half the features account for $200K of this monthly returnFeatures begin earning money 1 month after releaseEach month of development costs $100KEach release costs $100K
Technical Considerations
Continuous Integration
Build on demand
Execute all tests
Build integrity in
Progressive design
Implemented with end-to-end functionality
Exemplified through test coverage and refactoring
Scaling the Product Owner
ProductOwners
Product LineOwners
Chief ProductOwner
Who has the ‘D’?