Speak To The Business! Agile Metrics That Inform Rather Confuse the Business

Speak To The Business!

“If you give a manager a target, he will meet it, even if he has to destroy the organization to do

so.”

--W. Edwards Deming

Agile Metrics That Inform Rather Confuse the Business

Troy Tu'le, KCP Principal Consultant, Owner KanFlow.com [email protected] @troytuDle

Why do we use Metrics?

To help us make informed decisions!

Definitions of “Agile” metrics terms:

Velocity: At the end of each iteration, the team adds up effort estimates (“story points”) associated with user stories that were completed during that iteration. This total is called velocity. – Agile Alliance

Story Points: Agile teams generally prefer to express estimates in units other than the time-honored "man-day" or "man-hour". Story points are purposely dimensionless. -- Agile Alliance

Example: Options for sizing stories are (1, 2, 3, 5, 8, 13, 20, 40, 100). Based on what was completed, the team’s velocity is 25 story points per iteration.

What is Velocity?

“Yippee! Our Velocity went from 25 to 35 story points the last 2 sprints.

Let’s go celebrate!”

What is a Story Point?

So the team does relaQve esQmaQon. At any Qme, they can change a “5” to an “8”

and increase their Velocity next sprint. And we should celebrate this???

The mistrust of story points

What about Story Point predictability?

Don’t story points help us predict when a batch of unequal-‐sized stories will be completed?

The following data examples are all from real-‐world so[ware teams or companies…

Story point myopia

-‐-‐ Jim Benson, moduscooperandi.com

16 72 21 19 37

Velocity in Story Points

7 9 9 9 7

Throughput in Card Count

Velocity is a proxy metric

Story points are designed to be abstract.

Velocity is an aDempt to plan work based on an abstracQon, based on an esQmate.

SomeQmes this causes unnecessary confusion and drama!

Unfortunate side effect

Velocity (based on story points) has become a social and business currency.


X X X X X X X X

?


@duarte_vasco

-‐Vasco Duarte hDp://bit.ly/vasco_blog

24 sprint project


Courtesy of Bennet Vallet

Director of Development

Siemens Health Services

Expected DistribuQon Actual DistribuQon

Next you will see the forecasted release date when using Story Points (values

1:2:3)


48 49 46 46 44 43 42 42

37 37 36 35

0

10

20

30

40

50

60

70

80

90

Release on 12th October

2014


Next you will see the forecasted release date when using Story Points (values

1:3:5)


68 68 64 64 62 60 59 59

52 52 51 50

0

20

40

60

80

100

120

140

Release on 18th October

2014


Next you will see the forecasted release date when just counQng

number of stories (or, all stories = 1 story point)


28 30 28 28 26 26 25 25 22 22 21 20

0

10

20

30

40

50

60

70

80

90

1/1

1/3

1/5

1/7

1/9

1/11

1/13

1/15

1/17

1/19

1/21

1/23

1/25

1/27

1/29

1/31

2/2

2/4

2/6

2/8

2/10

2/12

2/14

2/16

2/18

2/20

2/22

2/24

2/26

2/28

3/1

3/3

3/5

3/7

3/9

Release on 27th September 2014


Conclusion...


All dates within 3 weeks of each other in a 38 to 42 week

project


Data used with permission from Bill Hanlon at Microso[

”At that point, I stopped thinking that es:ma:ng

was important.”

Bill Hanlon: hDp://bit.ly/BHanlon

Data VisualizaQons courtesy of Vasco Duarte hDp://bit.ly/vasco_blog @duarte_vasco

Get out of the Cult

“Cargo Cult Agile”

Many 1st generaQon Agile aDempts simply installed pracQces (recipes).

Following recipes leads to Cargo Cult Agile

No estimation, seriously?

#noesQmates started as a conversaQon on TwiDer and grew into a movement within the Agile community.

If we reject being in an Agile Cargo Cult, we can quesQon the status quo, and ask

Why?

Sure! But we need some good, old fashioned, Agile discipline…

Can we do this work without esQmaQng?

The #noestimates Playbook

•  Dedicated and stable teams •  Right size user stories •  Iterate and deliver frequently •  Drip Feed or Investment Funding •  Track lead time and throughput •  Speak the language of the business!

(don’t use terms from physics) •  Don’t use bullet points in your slides


Op<on #1 Hours-‐long tradiQonal sprint planning meeQngs spent playing planning poker and a team arguing about the difference between 2’s and 3’s.

Op<on #2 Short story slicing meeQng where the focus is on understanding and slicing large stories. “Do we understand this story? If not, let’s keep slicing.”

1 2 3 5 8 13 20 40 100

Right-‐sizing the work


Input Q Design Develop Test Done 1 2 1

3

1 2

9

7

8

6

4

5

Lead Time

Throughput

10

14 days from this point

5 stories per week

MVP A

Upstream Planning

1. PrioriQze

2. Analyze S

S S

S S S

S S

S S

MVP B

Cumulative Flow Diagram

Courtesy of AcQonableAgile.com

Scatter Plot Diagram

Courtesy of AcQonableAgile.com


If we start a new story today, we expect to complete it in:

ProbabilisQc ForecasQng

<= 6 days (50th percenQle) <= 15 days (85th percenQle) <= 22 days (95th percenQle)

If we start a batch of 20 stories today, we expect to complete them in:

>= 9 days (throughput of 2.33 / day)

Summary

•  Speak the language of the business, use “throughput” and “lead time” instead of the proxy metrics of “story points” and “velocity”

•  Metrics that are transparent and based on the actual system’s capacity, are generally more actionable.

•  Beware of Cargo Cult Agile. Know why you observe certain practices. Be willing to question!

Speak To The Business!

“If you give a manager a target, he will meet it, even if he has to destroy the organization to do

so.”

--W. Edwards Deming

Agile Metrics That Inform Rather Confuse the Business

Troy Tu'le, KCP Principal Consultant, Owner KanFlow.com [email protected] @troytuDle

Speak To The Business! Agile Metrics That Inform Rather Confuse the Business

Software

Transcript of Speak To The Business! Agile Metrics That Inform Rather Confuse the Business