OL-03
Sub-LCL Completion — Workflow Bypass
Outliers
Default severity: medium
MetricsOutputQualityRisk
What it detects
Items completing faster than the configured minimum realistic time for their issue type — indicates DoD bypass, wrong board, or data quality issue. Minimum thresholds are configurable per issue type.
Detection formula
LCL_min = config.lcl.minimum_time\[issue_type\] // e.g. Epic: 5d, Story: 4h, Task: 30m IF issue.cycle_time \< LCL_min THEN AUDIT Cross-reference with changelog: does the item have the expected number of transitions?Examples in practice
- A story moves from In Progress to Done in 20 minutes — below the minimum realistic cycle time for that issue type.
- An epic is marked Done without the expected number of workflow transitions in the changelog.
- Fast closure suggests DoD bypass, wrong board usage, or corrupted timestamps.
Suggested response
Validate whether outliers reflect real incidents or data and process issues before changing targets.
Coaching playbook
Symptom
Items completing faster than the configured minimum realistic time for their issue type — indicates DoD bypass, wrong board, or data quality issue. Minimum thresholds are configurable per issue type.
Why it matters
When "Sub-LCL Completion — Workflow Bypass" 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
Validate whether outliers reflect real incidents or data and process issues before changing targets.
Facilitation questions
- What system change would stop "Sub-LCL Completion — Workflow Bypass" 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.