SA-04
Sprint Velocity Composed Primarily of Non-Feature Work
Sprint Anomalies
Default severity: medium
ProcessMetricsQuality
What it detects
More than the configured proportion of sprint velocity (completed SP) comes from non-feature issue types (bugs, tech debt, tasks, spikes) rather than user stories or features — the team appears productive but is not delivering user-facing value. feature_sp = SUM(sp, issues WHERE type IN config.it.feature_types AND status=Done, sprint=S) total_velocity = SUM(sp, all Done issues, sprint=S) feature_pct = feature_sp / max(1, total_velocity)
Detection formula
IF feature_pct \< config.sa.min_feature_velocity_pct // default: 0.60 (60% of velocity must be features) THEN FLAG IF feature_pct \< config.sa.critical_feature_velocity_pct // default: 0.40 THEN CRITICAL Report: velocity breakdown by issue type per sprint as time seriesExamples in practice
- A team shows more than the configured proportion of sprint velocity (completed sp) comes from non-feature issue types (bugs, tech debt, tasks, spikes) rather than user stories or features while min feature velocity pct is set to 0.60 (60% of velocity must be features).
- Example signal: More than the configured proportion of sprint velocity (completed SP) comes from non-feature issue types (bugs, tech debt, tasks, spikes) rather than user stories or features — the team appears productive but is not delivering user-facing value.
Suggested response
Keep sprint boundaries honest—resolve, replan, or flag anomalies instead of hiding them.
Coaching playbook
Symptom
More than the configured proportion of sprint velocity (completed SP) comes from non-feature issue types (bugs, tech debt, tasks, spikes) rather than user stories or features — the team appears productive but is not delivering user-facing value. feature_sp = SUM(sp, issues WHERE type IN config.it.feature_types AND status=Done, sprint=S) total_velocity = SUM(sp, all Done issues, sprint=S) feature_pct = feature_sp / max(1, total_velocity)
Why it matters
When "Sprint Velocity Composed Primarily of Non-Feature Work" 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
Keep sprint boundaries honest—resolve, replan, or flag anomalies instead of hiding them.
Facilitation questions
- What system change would stop "Sprint Velocity Composed Primarily of Non-Feature Work" 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.