Value over velocity - Ryan Shriver

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


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


IT Opera>ons

VP of Marke>ng

Development Team

VP of Sales

Legal

Procurement

Business Partners

Iden>fying the Top Goals


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




Iden>fy and




Create or Update

Backlog of Stories

Measure Points and

Stories Delivered

Es>mate Stories and

Points to Deliver


Make Value-based

Decisions


Measure Value

Delivered

Why Quan>fy Goals?


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


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


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


Visualizing Goals

19

Baselines, Targets and Constraints exist along an improvement con%nuum

Fail

Constraint

0%

Target

100%

Baseline

30%

Success


Opportunity




Iden>fy and




Create or Update

Backlog of Stories

Measure Points and

Stories Delivered

Es>mate Stories and

Points to Deliver


Make Value-based

Decisions


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


IT Opera>ons

VP of Marke>ng

Development Team

VP of Sales

Legal

Procurement

Business Partners


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


IT Opera>ons

VP of Marke>ng

Development Team

VP of Sales

Legal

Procurement

Business Partners


Queue

Work Item 1

Work Item 2

Work Item 3 Top Idea

Quan>ed Goals

Idea #1 Idea #2 Idea #3 Idea #n




Iden>fy and




Create or Update

Backlog of Stories

Measure Points and

Stories Delivered

Es>mate Stories and

Points to Deliver


Make Value-based

Decisions


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


Fail

Constraint

0%

Target

100%

Baseline

30%

Success


Opportunity

Measure Value Delivered

27


Fail

Constraint

0%

Target

100%

Old Baseline

30%

Success


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

Documents

Value over velocity - Ryan Shriver