[groby_b]

I am still not clear at all how "cycle time" is a meaningful measure without correcting for size of the feature.

I'm also confused as to how you can look at "mean of one week, with a standard deviation of two weeks" and not wonder about the asymmetry of the distribution, and if mean/sd are really the metrics of choice here. (I'd think 1st/3rd quartile are a better choice, because it gives some clue as to skewedness)

[judofyr]

I'm guessing it's a good metric here because most of their tasks are small tasks that only takes a few hours to complete (in code) and then the average Cycle Time becomes the average overhead for getting a fix into production.

[lmm]

I'd say SD is a much better measure here, precisely because that big standard deviation jumps out at you. My guess would be that the 3rd quartile is some sensible-sounding number like 1.2 weeks but there are some huge outliers pulling up the SD.

[snorberhuis]

I agree that the Standard Deviation is a good measurement because of the big outliers.

We also focus on these during retro. What made us remarkably slow? You want to drive down these issues.

This investigation can help you in future work. I worked with another team that was consistently slow if they would need to build new pipelines or get connections up and running to third parties(heavy regulated environment). This insight helped us in planning.