Cycle Time Metrics & The Downfall of Story Points

HDC 2013Scott Aucoin

Evolution from

^

Me

You?

?

What the heck is a Cycle Time?

A Step Back

“Scientific Management”

Waterfall

Agile

Lean

PSP & TSP

Method-Neutral Constants

• Need for:– Scheduling– Forecasting– Estimation

• Risk & Unknowns• The need to know speed

Cycle Times

• Methodology Neutral Measurement• Tool for understanding the big picture

and all of the little pictures within it• Think Lean Manufacturing

Cycle Time

Easy as Cake

Scenario IntroductionBacklog Ready… In… Ready… In… Ready

for Signoff

Done

- Req’ts

- To Do

- Ready for Dev

- Ready for UX

- Ready for Design

- In Progress

- In Dev

- In UX

- In Design

- Ready for QA

- Ready for Staging

- In QA

- Testing

- Build

- Ready for Signoff

- Ready for PO

- Ready for Build

- Ready for Prod

- Ready for X

- Approved

Scenario IntroductionTo Do In Progress Done

Scenario In ProgressBacklog Ready

for DevIn Dev Ready

for QAIn QA Ready

for Signoff

Approved

#10

Story Chore Bug

#12

#23

#14

#8

#3#9

#7

Scenario In ProgressBacklog Ready

for DevIn Dev Ready

for QAIn QA Ready

for Signoff

Approved

#10

Story Chore Bug

#12

#23

#14

#8

#3#9#7

In Dev: 1.2 daysReady for QA: .5In QA: 1Ready for Signoff: 2 daysTotal: 4.7 days

Cycle Time Definition

The time it takes for a unit to move through a development process

• Unit is any piece of work: Story, Chore, Defect/Bug, Technical Task, etc.

• Can be measured at the highest level (start to finish) or incremental levels (as small as you can)

• The value is based on what you put into it

How To:Req. # Type Ready

DevIn Dev Ready

QAIn QA Ready

AcceptTotal

12 Story .4 .25 .5 1 2.4

9 Story .5 1 .5 .25 1.5 4.5

14 Chore 1.5 1.5

26 Story .5 1.5 1 .5 .25 3.75

33 Bug .75 .3 1.4 1.25 3.9

When To:

• As is the case with “How to” – it depends on the tools you use

• Grab the data as frequently as you can, always better to do it as soon as possible

• The rule is up to you

How can I use the Cycle Time?

Scenario FlashbackBacklog Ready

for DevIn Dev Ready

for QAIn QA Ready

for Signoff

Approved

#10

Story Chore Bug

#12

#23

#14

#8

#3#9

#7

How To Flashback:Req. # Type Ready

DevIn Dev Ready QA In QA Ready

AcceptTotal # of

Handoffs

12 Story .4 .25 .5 1 2.15 3

9 Story .5 1 .5 .25 1.5 3.75 5

14 Chore 1.5 1.5 0

26 Story .5 1.5 1 .5 .25 3.75 4

33 Bug .75 .3 1.4 1.25 3.9 3

Endless Opportunities

• Individual Efficiency• Pair Productivity• Process changes (intro of new tools)• Knowledge of handbacks• Ability to plan when a person (or

entire skill set) will not be available and know the impact based on data

• Planning, forecasting, estimating…

Overhead from Planning

• Time = Money• Inaccurate Estimates– Waterfall = 14% success– Agile = 42% success– PSP/TSP = 94% accurate (small sample & consider

the significant overhead)

“Humans aren't very good at estimating in general, regardless of what measure is used.” – Joshua Kerievsky

Time is money & estimates are often inaccurate

Meeting Time vs Productivity

Evolving from Story Points

How To Flashback #2:Req. # Type Ready

DevIn Dev Ready

QAIn QA Ready

AcceptTotal # of

Handoffs# of Story Pts

12 Story .4 .25 .5 1 2.4 3 3

9 Story .5 1 .5 .25 1.5 4.5 5 5

14 Chore 1.5 1.5 0 1

26 Story .5 1.5 1 .5 .25 3.75 4 8

33 Bug .75 .3 1.4 1.25 3.9 3 5

Measuring Points

#NoEstimates

• Pull the carpet out from story points and use total # of units (stories + chores + bugs, etc.)

• Balance slices or come to terms with tradeoffs – Big tickets will balance out with little ones

“Using story counting does not imply that all the stories are roughly the same size (although some teams do work that way). Stories can still vary in size, but over time the bigger and smaller stories will cancel each other out, hence a simple count ends up the same.” – Martin Fowler

Benefits of Unit-based Planning

• Standardize expectations & remove opportunity for inflation

• Save engineering time• Use ongoing data to plan more

accurately and with less overhead

Scott Aucoin@HawkingsMentor