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



comments powered by Disqus