View
242
Download
0
Category
Preview:
Citation preview
1
Certified Scrum Product Owner
www.agilecrossing.com
1
Certified Scrum Product Owner
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
21
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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
Certified Scrum Product Owner
www.agilecrossing.com
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: roger@agilecrossing.com
Twitter: rwbrown
Blog: www.agileCoachJournal.com
LinkedIn: http://www.linkedin.com/in/rogerwbrown
V2.5
149
Certified Scrum Product Owner
Instructor – Roger Brown CST, CSC
Training Transition
Transformation
All slides © 2014 Roger W. Brown
Recommended