Deck from a talk on cycle times and how to apply them for informed decision making (forecasting, team building, balance, process improvement) and evolution from traditional estimation approaches.
12. Cycle Times
⢠Methodology Neutral Measurement
⢠Tool for understanding the big picture
and all of the little pictures within it
⢠Think Lean Manufacturing
15. Scenario Introduction
Backlog 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
17. Scenario In Progress
Backlog Ready for
Dev
In Dev Ready for
QA
In QA Ready for
Signoff
Approved
#10
Story Chore Bug
#12
#23
#14
#8
#3#9
#7
18. Scenario In Progress
Backlog Ready for
Dev
In Dev Ready for
QA
In QA Ready for
Signoff
Approved
#10
Story Chore Bug
#12
#23
#14
#8
#3#9#7
In Dev: 1.2 days
Ready for QA: .5
In QA: 1
Ready for
Signoff: 2 days
Total: 4.7 days
19. 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
20. How To:
Req. # Type Ready
Dev
In Dev Ready QA In QA Ready
Accept
Total
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
21. 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
27. Scenario Flashback
Backlog Ready for
Dev
In Dev Ready for
QA
In QA Ready for
Signoff
Approved
#10
Story Chore Bug
#12
#23
#14
#8
#3#9
#7
28. How To Flashback:
Req. # Type Ready Dev In Dev Ready QA In QA Ready
Accept
Total # 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
29.
30.
31.
32. 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âŚ
33. 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
36. How To Flashback #2:
Req. # Type Ready Dev In Dev Ready QA In QA Ready
Accept
Total # 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
38. #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
39. 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
