CC-04

Std Dev Band Too Wide

Control Chart

Default severity: medium
ProcessMetricsOutputRisk

What it detects

Standard deviation band width exceeds the configured multiple of the average cycle time — process is out of statistical control. band_width = UCL - LCL

Detection formula

IF band_width > avg * config.cc.max_band_width_ratio // default: 1.5x THEN FLAG IF band_width > avg * config.cc.critical_band_width_ratio // default: 2.0x THEN CRITICAL

Examples in practice

  • Rolling averages, control limits, or band width diverge from expected statistical bounds.
  • Recent control-chart windows show drift, clusters, or missing limit configuration.
  • A team shows standard deviation band width exceeds the configured multiple of the average cycle time while max band width ratio is set to 1.5x.

Suggested response

Treat the metric as a control signal: confirm limits, windows, and cross-team spread before acting.

Coaching playbook

Symptom

Standard deviation band width exceeds the configured multiple of the average cycle time — process is out of statistical control. band_width = UCL - LCL

Why it matters

When "Std Dev Band Too Wide" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.

What you can achieve

Treat the metric as a control signal: confirm limits, windows, and cross-team spread before acting.

Facilitation questions

  • What system change would stop "Std Dev Band Too Wide" from firing again?
  • What do the cited issues have in common — same root cause or same workaround?
  • Who owns the two-week experiment and how will we verify on the next import?

Run this rule against your own tracker data with Flow Analyzer.

Product tourSign in
CC-04: Std Dev Band Too Wide — FlowAnalyzer