OI-05
Operational Issues Proportion — Team-Level Impact
Operational Issues
Default severity: medium
Product BacklogProcessMetrics
What it detects
The proportion of a team\'s issues that are classified as operational trackers exceeds the configured threshold — the team is using Jira extensively for operational logging, which inflates all their flow metrics. At high proportions, the team\'s control chart and CFD data are primarily driven by operational issues, not deliverable work.
Detection formula
FOR each_team T: oi_count(T) = COUNT(issues WHERE OI-01 flagged AND team=T) total_count(T) = COUNT(all_active_issues, team=T) oi_pct(T) = oi_count(T) / total_count(T) IF oi_pct(T) > config.oi.team_oi_warning_pct // default: 0.10 (10% of issues are operational) THEN FLAG IF oi_pct(T) > config.oi.team_oi_critical_pct // default: 0.20 (20%) THEN CRITICAL — team metrics are heavily contaminated Report: oi_pct per team, estimated metric contamination percentageExamples in practice
- A team shows the proportion of a team\'s issues that are classified as operational trackers exceeds the configured threshold while team oi warning pct is set to 0.10 (10% of issues are operational).
- Example signal: The proportion of a team\'s issues that are classified as operational trackers exceeds the configured threshold — the team is using Jira extensively for operational logging, which inflates all their flow metrics.
Suggested response
Separate operational trackers from product flow or exclude them consistently from delivery metrics.
Coaching playbook
Symptom
The proportion of a team\'s issues that are classified as operational trackers exceeds the configured threshold — the team is using Jira extensively for operational logging, which inflates all their flow metrics. At high proportions, the team\'s control chart and CFD data are primarily driven by operational issues, not deliverable work.
Why it matters
When "Operational Issues Proportion — Team-Level Impact" 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
Separate operational trackers from product flow or exclude them consistently from delivery metrics.
Facilitation questions
- What system change would stop "Operational Issues Proportion — Team-Level Impact" 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.