This document discusses value-based prioritization and goal setting for agile teams. It begins with an introduction of the speaker and overview of the agenda, which includes identifying key stakeholder goals, quantifying those goals for clarity, and integrating goals into agile delivery planning. The document then defines relevant terms like stakeholder, value, and feature. It emphasizes focusing on delivering value to stakeholders over building features. The remainder discusses processes for identifying and quantifying goals of different stakeholder types like customers and business leaders to prioritize work.

1. Ryan
Shriver
Value over Velocity rshriver@ddig.com
@ryanshriver
From Feature Building to Value Delivery
1
theagileengineer.com

2. Leader
of
IT
Performance
Improvement
Solu>ons
for
Dominion
Digital
in
Richmond,
Virginia
Background
in
Development.
Now
focused
on
Agile
Transforma>ons

3. Today’s
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
stakeholder’s
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
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
3

4. Assump>ons
• You
care
about
Value
and
want
to
learn
techniques
for
defining
and
measuring
value
• Agile
and
Kanban
works.
Don’t
change
them,
enhance
them
• Your
teams
are
delivering
rela>vely
well
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
4

5. Value
over
Velocity
Effec%veness
over
Efficiency
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
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
5

6. Value
Defini>ons
Stakeholder
Any
person,
group
or
object
which
has
some
direct
or
indirect
interest
in
a
system.
They
define
their
Value.
Value
A
perceived
benefit,
that
is,
the
benefit
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
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
6

7. Value
Delivery
Process
Iden>fy
Es>mate
Measure
Iden>fy
Create
or
and
Iden>fy
Stories
Delivery
with
Points
Stake-­‐ Update
Priori>ze
Winning
and
•
Scrum
and
holder
Backlog
of
Stake-­‐ Ideas
Points
to
•
Kanban
Stories
Goals
Stories
holders
Deliver
Delivered
Quan>fy
Make
Es>mate
Measure
Stake-­‐ Value-­‐
Value
to
Value
holder
based
Deliver
Delivered
Goals
Decisions
Today’s
Focus
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
7

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

9. Iden>fying
Business
Goals
VP
of
Marke>ng
• Work
with:
VP
of
Sales
– Execu>ve
Sponsors
Business
– Internal
Stakeholders
Partners
– Product
Owner
Development
• Iden>fy:
Team
– Stakeholders
with
Direct
or
Indirect
Interest
in
the
IT
Opera>ons
Product
or
Project
– Priori>ze
for
Focus
Procurement
• For
Highest
Priority
Stakeholders:
Legal
– Names
– Goals
&
Values
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
9

10. Iden>fying
the
Top
Goals

Improve
Ease
of
Use

Decrease
Problem
Resolu>on
Time
VP
of

Improve
Customer
Self
Service
Marke>ng
VP
of
Sales

Reduce
Time
to
Market
Business
Partners

Reduce
Defects
Development
Team
IT
Opera>ons
Procurement
Legal
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
10

11. Value
Delivery
Process
Iden>fy
Es>mate
Measure
Iden>fy
Create
or
and
Iden>fy
Stories
Delivery
with
Points
Stake-­‐ Update
Priori>ze
Winning
and
•
Scrum
and
holder
Backlog
of
Stake-­‐ Ideas
Points
to
•
Kanban
Stories
Goals
Stories
holders
Deliver
Delivered
Quan>fy
Make
Es>mate
Measure
Stake-­‐ Value-­‐
Value
to
Value
holder
based
Deliver
Delivered
Goals
Decisions
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
11

12. Why
Quan>fy
Goals?
“The
fact
that
we
should
set
“Goals
provide
an
objec>ve
and
numeric
improvement
a
focus.
They
help
us
to
set
objec>ves,
and
track
their
priori>es
and
to
ignore
delivery
numerically,
is
powerful;
unimportant
details.
To
achieve
but
it
is
not
the
main
point.
The
something
important,
start
by
main
purpose
of
quan>fica>on
is
defining
precisely
what
you
are
to
force
us
to
think
deeply,
trying
to
accomplish.
Vague
debate,
agree,
and
specify,
direc>ons
and
imprecise
goals
exactly,
what
we
mean;
so
that
waste
>me.”
others,
later,
cannot
fail
to
–
Wa@s
Humphrey
understand
us.”
-­‐
Tom
Gilb
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
12

13. How
to
Quan>fy
a
Goal
Name:
In
the
form
Ac%on
Verb
+
Noun
Phrase
Step
1
Scale:
What
to
measure
(units)
Meter:
How
to
measure
(method)
Baseline:
Current
level
Step
2
Target:
Success
level
to
achieve
Constraint:
Failure
level
to
avoid
Op>onal
Elements
Defini'ons:
To
clarify
terminology
and
meaning
[Qualifiers]:
Specificity
and
Reusable
Scales
<-­‐
Sources:
Addi>onal
transparency
and
credibility
Source:
Based
on
Planguage
from
Compe%%ve
Engineering
by
Tom
Gilb
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
13

14. Real
Example
of
Stakeholder
Goal
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
Total
requests
counted
by
Customer
Care
Measurement
Monthly
report
of
calls
to
Customer
Care
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
14

15. Types
of
Scales
Leading
Indicators
Lagging
Indicators
• Focused
on
future
• Focused
on
past
developments
and
drivers
/
developments
and
effects
/
causes
results
• Measurements
can
be
done
• Measurements
must
wait
for
right
now
passage
of
>me
• Examples:
• Examples:
– Average
response
>me
– Quarterly
Revenue
– Average
handle
>me
– Total
incidents
last
month
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
15

16. Baselines
Common
methods
for
establishing
Baseline
levels
include
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
there’s
no
suppor>ng
data.
Use
the
<-­‐
source
tag
to
indicate
credibility
of
data
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
16

17. Targets
and
Constraints
Common
methods
for
establishing
Target
and
Constraint
levels
include
Method
Descrip'on
Improvement
from
the
Baseline
Plan
a
20%
-­‐
40%
improvement
over
current
levels
by
next
year
Comparison
with
Leading
Benchmarking
yourself
against
leading
Compe>tors
compe>tors
and
seqng
levels
based
on
their
capabili>es
Comparison
with
your
Industry
Benchmarking
yourself
against
your
industry
Leaders
leaders,
such
as
trying
to
be
in
Gartner’s
Magic
Quadrant
Comparison
with
other
Industry
Benchmarking
yourself
against
other
Leaders
industries
known
for
great
levels
of
quality,
such
as
Nordstrom’s
customer
service
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
17

18. Real
Example
of
Stakeholder
Goal
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
Total
requests
counted
by
Customer
Care
Measurement
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
18

19. Visualizing
Goals
Baselines,
Targets
and
Constraints
exist
along
an
improvement
con%nuum
Constraint
Baseline
Target
Fail
Opportunity
Success
0%
30%
100%
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
19

20. Value
Delivery
Process
Iden>fy
Es>mate
Measure
Iden>fy
Create
or
and
Iden>fy
Stories
Delivery
with
Points
Stake-­‐ Update
Priori>ze
Winning
and
•
Scrum
and
holder
Backlog
of
Stake-­‐ Ideas
Points
to
•
Kanban
Stories
Goals
Stories
holders
Deliver
Delivered
Quan>fy
Make
Es>mate
Measure
Stake-­‐ Value-­‐
Value
to
Value
holder
based
Deliver
Delivered
Goals
Decisions
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
20

21. Value
Decision
Table
for
Iden'fy
Winning
Ideas
Poten'al
Ideas
Goals
Totals
Idea
#1
Idea
#2
Idea
#3
Improve
Ease
of
Use
Time
to
find
info:
120
secs
-­‐>
20
secs
20%
+/-­‐
10%
40%
+/-­‐
20%
70%
+/-­‐
30%
130%
+/-­‐
60%
Decrease
Problem
Resolu>on
Time
Avg
%me:
72
hours
-­‐>
24
hours
50%
+/-­‐
10%
20%
+/-­‐
20%
50%
+/-­‐
10%
120%
+/-­‐
40%
Improve
Customer
Self
Service
90%
+/-­‐
30%
0%
+/-­‐
0%
50%
+/-­‐
20%
40%
+/-­‐
10%
Online
Services:
0
-­‐>
10
Total
Benefits
70%
+/-­‐
20%
110%
+/-­‐
60%
160%
+/-­‐
50%
Resources
Cost
(in
Story
Points)
23
48
75
146
Total
Benefits
/
Cost
Ra>o
3.0
+/-­‐
0.9
2.3
+/-­‐
1.3
2.1
+/-­‐
0.5
Design
with
highest
ra%o
is
best
“bang
for
the
buck”
and
will
deliver
value
quicker

22. Scrum:
Linking
Personas
to
Goals,
Ideas
and
Backlogs

Improve
Ease
of
Use

Decrease
Problem
Idea
#1
Resolu>on
Time
Idea
#2

Improve
Customer
Self
Idea
#3
f
>ng
Service
Idea
#n
VP
of
Sales

Reduce
Time
to
Market
ess

Reduce
Defects
ers
Development
Backlog
Team
>ons
Quan>fied
Story
1
Procurement
Goals
Story
2
Top
Idea(s)
l
Story
3
Story
n
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
22

23. Kanban:
Linking
Personas
to
Goals,
Ideas
and
Backlogs

Improve
Ease
of
Use

Decrease
Problem
Resolu>on
Time
Idea
#1

Improve
Customer
Self
Idea
#2
f
Service
Idea
#3
>ng

Reduce
Time
to
Market
Idea
#n
VP
of
Sales
ess

Reduce
Defects
ers
Development
Queue
Team
>ons
Quan>fied
Work
Item
1
Procurement
Goals
Work
Item
2
Top
Idea
l
Work
Item
3
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
23

24. Value
Delivery
Process
Iden>fy
Es>mate
Measure
Iden>fy
Create
or
and
Iden>fy
Stories
Delivery
with
Points
Stake-­‐ Update
Priori>ze
Winning
and
•
Scrum
and
holder
Backlog
of
Stake-­‐ Ideas
Points
to
•
Kanban
Stories
Goals
Stories
holders
Deliver
Delivered
Quan>fy
Make
Es>mate
Measure
Stake-­‐ Value-­‐
Value
to
Value
holder
based
Deliver
Delivered
Goals
Decisions
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
24

25. Plan
and
Measure
Value
Delivered
Release
1
Release
2
Goals
Es'mate
Actual
Es'mate
Actual
Idea
#1
Idea
#1
Improve
Ease
of
Use
Time
to
find
info:
120
secs
-­‐>
20
secs
20%
+/-­‐
10%
23%
(97
secs)
Decrease
Problem
Resolu>on
Time
Avg
%me:
72
hours
-­‐>
24
hours
50%
+/-­‐
10%
42%
(52
hours)
Improve
Customer
Self
Service
Online
Services:
0
-­‐>
10
0%
+/-­‐
0%
0%
Delivery
Using
Scrum,
Lean
or
Kanban
Repriori'ze,
Refine
and
Repeat
Repriori>ze:
Need
to
repriori>ze
goals
based
on
value
delivered?
Refine:
Update
target
and
constraint
levels
based
on
updated
baselines
Repeat
process
un>l
priori>es
change
or
no
more
resources
25

26. Measure
Value
Delivered
Baselines,
Targets
and
Constraints
exist
along
an
improvement
con%nuum
Constraint
Baseline
Target
Fail
Opportunity
Success
0%
30%
100%
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
26

27. Measure
Value
Delivered
Baselines,
Targets
and
Constraints
exist
along
an
improvement
con%nuum
Constraint
Old
Baseline
New
Baseline
Target
Value
Fail
Delivered
Opportunity
Success
0%
30%
70%
100%
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
27

28. 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,
Configurability,
Portability,
Compa>bility
Source:
FURPS
model
developed
at
Hewlew-­‐Packard
and
documented
by
Robert
Grady
and
Deborah
Caswell
in
Sotware
Metrics:
Establishing
a
Company
Wide
Program
(1987)
28

29. Quan>fying
Usability
–
Real
Example
Name:
Usability
Scales:
Efficiency:
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:
Efficiency:
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:
Efficiency
[eCommerce;
Release
1]:
103
ac>ons
<-­‐
Average
of
10
usability
tests
Conversion
[eCommerce;
Q4
2009
–
Q2
2010]:
0.37%
<-­‐
Current
state
Target:
Efficiency
[eCommerce;
Release
2]:
62
ac>ons
<-­‐
40%
reduc%on
Conversion
[eCommerce;
Q4
2010
–
Q2
2011]:
0.5%
<-­‐
30%
increase,
industry
average
Constraint:
Efficiency
[eCommerce;
Release
2]:
93
ac>ons
<-­‐
10%
reduc%on
Conversion
[eCommerce;
Q4
2010
–
Q2
2011]:
0.43%
<-­‐
15%
increase
29

30. Today’s
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
stakeholder’s
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
Copyright
2010
Ryan
Shriver
-­‐
theagileengineer.com
30

31. Ryan
Shriver
Value over Velocity rshriver@ddig.com
@ryanshriver
From Feature Building to Value Delivery
31
theagileengineer.com