The Development Metrics You Should Use (But Don’t) - Catherine Swetel (https://www.youtube.com/watch?v=__7K_fDqVJs)
[ ]
start data end date
cycle time (means something else outside software development)
“When can this thing be done?” > “how certain do you want to be?” 90% sure we’ll deliver it in … days
why probabilities instead of standard-deviation? > our work is not normally distributed
hard minimum, soft minimum, no maximum, there can always be delays
patterns
multimodal: 2 clusters
Why is there a tail?
types of work
- mandatory 45 day babysitting time
- normal work
- boss: “drop everything, and do this now”
Do you want to use probability of all on one type of work?
==> responsiveness + predictability start time (task) end time (task)
this team: unit = month
added up # dots in a month
regular vs mandatory-45-day work items
frequency of trhoughtput
“I want these 5 features in this release”
85% of the time we delivered 6 items or more in a month
lagging: time in process
leading: rate arriving work vs rate done work
rate arriving work vs rate done work
more and more things in our system => don’t trust historical data
helps you decide if you should have faith in your predictions
NOT: to calculate probability
NOT: to calculate estimates
because uses arithmetic average
-–
unlabeled axes
attention -> trend
not comparison between teams
everyone in this org is trending up
- color blindness (huge amount of men)
- red / green => value judgement
no value judgement
- no shaming
- safety for real
inventor of story points is sorry for inventing it
flow efficiency time worked vs sitting time high-performance = 10-20% touch time vs 80% waiting time