Video: The Development Metrics You Should Use (But Don’t) - Catherine Swetel
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
1) mandatory 45 day babysitting time
2) normal work
3) 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