value over velocity - ryan shriver
DESCRIPTION
TRANSCRIPT
-
Ryan Shriver [email protected]
@ryanshriver theagileengineer.com
Value over Velocity From Feature Building to Value Delivery 1
-
Leader of IT Performance Improvement Solu>ons for Dominion Digital in Richmond, Virginia Background in Development. Now focused on Agile Transforma>ons
-
Todays Agenda 1. Iden'fy the Right Goals
Those key goals that deliver value to the highest priority stakeholders early
2. Quan'fy them for Clarity To ensure stakeholders desires are clearly
understood by everyone
3. Integrate with Agile and Kanban Delivery Priori>ze the work and plan releases around
improvements to the top goals 3 Copyright 2010 Ryan Shriver - theagileengineer.com
-
Assump>ons You care about Value and want to learn techniques for dening and measuring value
Agile and Kanban works. Dont change them, enhance them
Your teams are delivering rela>vely well
4 Copyright 2010 Ryan Shriver - theagileengineer.com
-
Value over Velocity From To
Building Features Delivering Value
Focus on Means Focus on Ends
Planning by Features Planning by Value
Maximizing Velocity Maximizing Value
As Delivery methods mature, I believe we need to bring greater clarity and focus on the items on the right
5 Copyright 2010 Ryan Shriver - theagileengineer.com
Eec%veness over Eciency
-
Value Deni>ons Stakeholder Any person, group or object which has some direct
or indirect interest in a system. They dene their Value.
Value A perceived benet, that is, the benet we think we will receive from something
Business Value A synonym for the value a business stakeholder will receive from something
Customer Value A synonym for the value a customer will receive from something
Feature Func>onality that allows a user to complete a task. Typically the what. Can be decomposed into one or more User Stories and priori>zed in the Backlog
Source: Adapted from Compe%%ve Engineering by Tom Gilb 6 Copyright 2010 Ryan Shriver - theagileengineer.com
-
Value Delivery Process
Copyright 2010 Ryan Shriver - theagileengineer.com 7
Delivery with Scrum Kanban
Iden>fy and
Priori>ze Stake-holders
Iden>fy Stake-holder Goals
Iden>fy Winning Ideas
Create or Update
Backlog of Stories
Measure Points and
Stories Delivered
Es>mate Stories and
Points to Deliver
Todays Focus
Quan>fy Stake-holder Goals
Make Value-based
Decisions
Es>mate Value to Deliver
Measure Value
Delivered
-
Iden>fying Customer Goals
Work with: Marke>ng and Sales Product Owner
Iden>fy: Target Customer Segments
Create Personas: S>cky Names Adjec>ves Back story Goals and Values
Copyright 2010 Ryan Shriver - theagileengineer.com 8
-
Iden>fying Business Goals
Work with: Execu>ve Sponsors Internal Stakeholders Product Owner
Iden>fy: Stakeholders with Direct or
Indirect Interest in the Product or Project
Priori>ze for Focus For Highest Priority
Stakeholders: Names Goals & Values
Copyright 2010 Ryan Shriver - theagileengineer.com 9
IT Opera>ons
VP of Marke>ng
Development Team
VP of Sales
Legal
Procurement
Business Partners
-
Iden>fying the Top Goals
Copyright 2010 Ryan Shriver - theagileengineer.com 10
IT Opera>ons
VP of Marke>ng
Development Team
VP of Sales
Legal
Procurement
Business Partners
Improve Ease of Use Decrease Problem Resolu>on Time Improve Customer Self Service Reduce Time to Market Reduce Defects
-
Value Delivery Process
Copyright 2010 Ryan Shriver - theagileengineer.com 11
Delivery with Scrum Kanban
Iden>fy and
Priori>ze Stake-holders
Iden>fy Stake-holder Goals
Iden>fy Winning Ideas
Create or Update
Backlog of Stories
Measure Points and
Stories Delivered
Es>mate Stories and
Points to Deliver
Quan>fy Stake-holder Goals
Make Value-based
Decisions
Es>mate Value to Deliver
Measure Value
Delivered
-
Why Quan>fy Goals?
Copyright 2010 Ryan Shriver - theagileengineer.com 12
The fact that we should set numeric improvement objec>ves, and track their delivery numerically, is powerful; but it is not the main point. The main purpose of quan>ca>on is to force us to think deeply, debate, agree, and specify, exactly, what we mean; so that others, later, cannot fail to understand us. - Tom Gilb
Goals provide an objec>ve and a focus. They help us to set priori>es and to ignore unimportant details. To achieve something important, start by dening precisely what you are trying to accomplish. Vague direc>ons and imprecise goals waste >me. Wa@s Humphrey
-
How to Quan>fy a Goal
13
Deni'ons: To clarify terminology and meaning [Qualiers]: Specicity and Reusable Scales onal transparency and credibility
Op>onal Elements
Name: In the form Ac%on Verb + Noun Phrase Scale: What to measure (units) Meter: How to measure (method)
Step 1
Baseline: Current level Target: Success level to achieve Constraint: Failure level to avoid
Step 2
Source: Based on Planguage from Compe%%ve Engineering by Tom Gilb Copyright 2010 Ryan Shriver - theagileengineer.com
-
Real Example of Stakeholder Goal
14
Increase Customer Self Service Scales Percentage of Top 11 Self Service Requests that can be done from My Account
Number of Customer Support Calls
Methods of Measurement
Total requests counted by Customer Care
Monthly report of calls to Customer Care
Copyright 2010 Ryan Shriver - theagileengineer.com
-
Types of Scales
Leading Indicators
Focused on future developments and drivers / causes
Measurements can be done right now
Examples: Average response >me Average handle >me
Lagging Indicators
Focused on past developments and eects / results
Measurements must wait for passage of >me
Examples: Quarterly Revenue Total incidents last month
Copyright 2010 Ryan Shriver - theagileengineer.com 15
-
Baselines
Method Descrip'on
Use Exis>ng Meter Use exis>ng method of measuring such as a report
Create a New Meter Create a new method of measuring. This requires the team to implement new capabili>es in order to measure in the future
Es>mate Do the best you can to es>mate what the exis>ng baseline is, even if theres no suppor>ng data. Use the
-
Targets and Constraints
Method Descrip'on
Improvement from the Baseline Plan a 20% - 40% improvement over current levels by next year
Comparison with Leading Compe>tors
Benchmarking yourself against leading compe>tors and seqng levels based on their capabili>es
Comparison with your Industry Leaders
Benchmarking yourself against your industry leaders, such as trying to be in Gartners Magic Quadrant
Comparison with other Industry Leaders
Benchmarking yourself against other industries known for great levels of quality, such as Nordstroms customer service
17
Common methods for establishing Target and Constraint levels include
Copyright 2010 Ryan Shriver - theagileengineer.com
-
Real Example of Stakeholder Goal
18
Increase Customer Self Service Scales Percentage of Top 11 Self Service Requests that can be done from My Account
Number of Customer Support Calls
Methods of Measurement
Total requests counted by Customer Care
Monthly report of calls to Customer Care
Baselines [All Requests; Current Release] 0% (0 of 11)
[Customer Care calls; monthly average Q1 & Q2 2010] 32,000
Targets [All Requests; Oct. Release]: 45% (5 of 11)
[Customer Care calls; monthly average 1 quarter ater rollout]: 29,900 20% decrease for 5 online service requests
Constraints [All Requests; Oct. Release]: 36% (4 of 11)
[Customer Care calls; monthly average 1 quarter ater rollout]: 31,000 10% decrease for 4 online service requests
Copyright 2010 Ryan Shriver - theagileengineer.com
-
Visualizing Goals
19
Baselines, Targets and Constraints exist along an improvement con%nuum
Fail
Constraint
0%
Target
100%
Baseline
30%
Success
Copyright 2010 Ryan Shriver - theagileengineer.com
Opportunity
-
Value Delivery Process
Copyright 2010 Ryan Shriver - theagileengineer.com 20
Delivery with Scrum Kanban
Iden>fy and
Priori>ze Stake-holders
Iden>fy Stake-holder Goals
Iden>fy Winning Ideas
Create or Update
Backlog of Stories
Measure Points and
Stories Delivered
Es>mate Stories and
Points to Deliver
Quan>fy Stake-holder Goals
Make Value-based
Decisions
Es>mate Value to Deliver
Measure Value
Delivered
-
Value Decision Table for Iden'fy Winning Ideas
Goals Poten'al Ideas
Totals
Resources
Cost (in Story Points)
Total Benets / Cost Ra>o
Design with highest ra%o is best bang for the buck and will deliver value quicker
Idea #1
20% +/- 10%
50% +/- 10%
0% +/- 0%
70% +/- 20%
23
3.0 +/- 0.9
Improve Ease of Use Time to nd info: 120 secs -> 20 secs
Decrease Problem Resolu>on Time Avg %me: 72 hours -> 24 hours
Improve Customer Self Service Online Services: 0 -> 10
Total Benets
Idea #2
40% +/- 20%
20% +/- 20%
50% +/- 20%
110% +/- 60%
48
2.3 +/- 1.3
Idea #3
70% +/- 30%
50% +/- 10%
40% +/- 10%
160% +/- 50%
75
2.1 +/- 0.5
130% +/- 60%
120% +/- 40%
90% +/- 30%
146
-
Scrum: Linking Personas to Goals, Ideas and Backlogs
Copyright 2010 Ryan Shriver - theagileengineer.com 22
IT Opera>ons
VP of Marke>ng
Development Team
VP of Sales
Legal
Procurement
Business Partners
Improve Ease of Use Decrease Problem Resolu>on Time Improve Customer Self Service Reduce Time to Market Reduce Defects
Quan>ed Goals
Backlog
Story 1
Story 2
Story 3
Story n
Top Idea(s)
Idea #1 Idea #2 Idea #3 Idea #n
-
Kanban: Linking Personas to Goals, Ideas and Backlogs
Copyright 2010 Ryan Shriver - theagileengineer.com 23
IT Opera>ons
VP of Marke>ng
Development Team
VP of Sales
Legal
Procurement
Business Partners
Improve Ease of Use Decrease Problem Resolu>on Time Improve Customer Self Service Reduce Time to Market Reduce Defects
Queue
Work Item 1
Work Item 2
Work Item 3 Top Idea
Quan>ed Goals
Idea #1 Idea #2 Idea #3 Idea #n
-
Value Delivery Process
Copyright 2010 Ryan Shriver - theagileengineer.com 24
Delivery with Scrum Kanban
Iden>fy and
Priori>ze Stake-holders
Iden>fy Stake-holder Goals
Iden>fy Winning Ideas
Create or Update
Backlog of Stories
Measure Points and
Stories Delivered
Es>mate Stories and
Points to Deliver
Quan>fy Stake-holder Goals
Make Value-based
Decisions
Es>mate Value to Deliver
Measure Value
Delivered
-
Plan and Measure Value Delivered
Goals Release 1 Release 2
Es'mate Actual Es'mate Actual
Delivery Using Scrum, Lean or Kanban Repriori'ze, Rene and Repeat Repriori>ze: Need to repriori>ze goals based on value delivered?
Rene: Update target and constraint levels based on updated baselines
Repeat process un>l priori>es change or no more resources
25
Improve Ease of Use Time to nd info: 120 secs -> 20 secs
Decrease Problem Resolu>on Time Avg %me: 72 hours -> 24 hours
Improve Customer Self Service Online Services: 0 -> 10
Idea #1
20% +/- 10%
50% +/- 10%
0% +/- 0%
Idea #1
23% (97 secs)
42% (52 hours)
0%
-
Measure Value Delivered
26
Baselines, Targets and Constraints exist along an improvement con%nuum
Fail
Constraint
0%
Target
100%
Baseline
30%
Success
Copyright 2010 Ryan Shriver - theagileengineer.com
Opportunity
-
Measure Value Delivered
27
Baselines, Targets and Constraints exist along an improvement con%nuum
Fail
Constraint
0%
Target
100%
Old Baseline
30%
Success
Copyright 2010 Ryan Shriver - theagileengineer.com
Opportunity
New Baseline
70%
Value Delivered
-
Right Quali>es for Sotware Func>onality
Features, User Stories, Capabili>es, Security Usability
Human factors, Aesthe>cs, Consistency, Documenta>on Reliability
Availability, Recoverability, Accuracy Performance
Responsiveness, Throughput, Scalability Supportability
Maintainability, Testability, Extensibility, Adaptability, Serviceability, Congurability, Portability, Compa>bility
28
Source: FURPS model developed at Hewlew-Packard and documented by Robert Grady and Deborah Caswell in Sotware Metrics: Establishing a Company Wide Program (1987)
-
Quan>fying Usability Real Example
29
Name: Usability Scales: Eciency: Number of Ac>ons to complete a Transac>on from a Loca>on Conversion: Percentage of Users who complete a Transac>on ater star>ng Meters: Eciency: Average observed results from usertes>ng.com usability tests Conversion: Google Analy>cs conversion report
Ac>ons: One of {Data entry, Click, Scroll}. Default is All Ac>ons Transac>on: One of {eCommerce [Shop, Purchase], Self Service [Ac>vate, Change Plan]} Loca>on: One of {Home Page, My Account}. Default is Home Page
Baseline: Eciency [eCommerce; Release 1]: 103 ac>ons
-
Todays Agenda Iden'fy the Right Goals
Those key goals that deliver value to the highest priority stakeholders early
Quan'fy them for Clarity To ensure stakeholders desires are clearly
understood by everyone
Integrate with Agile and Kanban Delivery Priori>ze the work and plan releases around
improvements to the top goals 30 Copyright 2010 Ryan Shriver - theagileengineer.com
-
Ryan Shriver [email protected]
@ryanshriver theagileengineer.com
Value over Velocity From Feature Building to Value Delivery 31