Development Metrics you should use (but don’t)
Speaker: Cat Swetel @CatSwetel
See the list of all blog posts from the conference

Breakfast is good. You should eat breakfast. So Fruit Loops?
Metrics are good. You should have metrics. So bad metrics?

Metrics should fall into four baskets: quality, responsiveness, productivity and predictablilty. Value isn’t called out because this is about development metrics.

“The RIGHTER we do the WRONG thing, the WRONGER we become”

Definitions: (in this presentation)

• start – when pulled work into team (not when requested)
• finished – when customers can user

Metric: Time in process

• Units of time for one unit of work
• Display as a satter plot to see trends over time
• Can look at average and 90% line (likely worst case). Would you rather hear 90% of the time it will just under two months or on average 20 days. Either way will be 53 days.
• Display as a bar chart frequency distribution. See mode (entry with most items). Also see if long tail pattern. Tells a story about predictability
• Weibull distribution – fat toward zero but tail trickles into infinity. This is like your commute. It usually takes X minutes but then sometimes something happens. (Remember from phrase: Weibull wiggle and they wobble but they don’t fall down)
• Figure out story from data. In this case, determined that thought all work was the same, but really two distinct types. Were able to detect that high priority items were rushed and everything else waited.
• Learned really had a multi-modal curve. Like two separate bell curves
• This covers responsiveness and predictability

Metric: Throughput

• Units of work per unit of time
• Team cares about total capacity
• Customer cares about how many new features
• Cover range so cn see high and low
• Ok to see dip while make improvements and then it goes up after. Expect productivity to drop before normalize around the change
• Can display as range (hard to read
• Can display bar chart showing probability for each number of requests
• This covers productivity and predictability

Metric: Time in state

• Need to collaborate across teams so wasted time waiting.
• “Touch time” is a very small percentage of the total time
• Helps determine where work is stuck
• Good if see trend that getting better/worse. Look at more recent data. Are ueues growing or shrinking.
• Do not make the bars red and green. Don’t want to avoid investing in improvement. Also, red/green colorblindness
• Can stack within bar to display work in different states
• Can display cummulative flow diagram as line graph
• Little’s Law – average time in system
• If arrival and departure rates don’t match, should affect expections
• This covers predictability

Provided warning about this being number in context,not an estimate. Statistics are just answers/numbers. A person needs to provide the story/context around them.

I really liked this talk. Going deep on why a few metrics are useful is great!