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