CA-03
Planning Event Arrival Spike
CFD Advanced
Default severity: medium
PrioritizationProcessMetricsOutputRisk
What it detects
A statistically significant step in total item count occurs within the configured window around a configured planning event date (PI planning, quarterly planning, etc.).
Detection formula
planning_dates = config.planning.event_dates // list of planning event dates, configurable spike_window = config.ca.planning_spike_window_days // default: 7d before/after event FOR each planning_date: spike = total_items(date + spike_window) - total_items(date - spike_window) IF spike > total_items(date) * config.ca.planning_spike_threshold // default: 10% THEN FLAG — predict Control Chart impact in config.ca.lag_weeks weeks // default: 3-5Examples in practice
- A team shows a statistically significant step in total item count occurs within the configured window around a configured planning event date (pi planning, quarterly planning, etc while event dates is set to 7d.
- Example signal: A statistically significant step in total item count occurs within the configured window around a configured planning event date (PI planning, quarterly planning, etc.
Suggested response
Use planning-event context when interpreting advanced CFD bottlenecks, spikes, and ageing WIP.
Coaching playbook
Symptom
A statistically significant step in total item count occurs within the configured window around a configured planning event date (PI planning, quarterly planning, etc.).
Why it matters
When "Planning Event Arrival Spike" 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
Use planning-event context when interpreting advanced CFD bottlenecks, spikes, and ageing WIP.
Facilitation questions
- What system change would stop "Planning Event Arrival Spike" 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.