BH-03
Burst Delivery Pattern
Backlog Health
Default severity: medium
Product BacklogPrioritizationRiskEffort
What it detects
Team shows silent periods longer than the configured minimum gap followed by delivery clusters within the configured burst window — Jira is not updated continuously.
Detection formula
silent_period_threshold = config.backlog.burst_silent_days // default: 30d burst_cluster_days = config.backlog.burst_cluster_days // default: 3d burst_min_count = config.backlog.burst_min_count // default: 5 IF ANY(silent_period >= silent_period_threshold) AND ANY(burst >= burst_min_count in burst_cluster_days) THEN FLAGExamples in practice
- A team shows team shows silent periods longer than the configured minimum gap followed by delivery clusters within the configured burst window while burst silent days is set to 30d burst_cluster_days = config.backlog.burst_cluster_days.
- Example signal: Team shows silent periods longer than the configured minimum gap followed by delivery clusters within the configured burst window — Jira is not updated continuously.
Suggested response
Refine or prune ageing, imbalanced, or inconsistently closed backlog items.
Coaching playbook
Symptom
Team shows silent periods longer than the configured minimum gap followed by delivery clusters within the configured burst window — Jira is not updated continuously.
Why it matters
When "Burst Delivery Pattern" 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
Refine or prune ageing, imbalanced, or inconsistently closed backlog items.
Facilitation questions
- What system change would stop "Burst Delivery Pattern" 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.