PL-03
Planning Period Carryover Without Label Update
Pipeline
Default severity: medium
ProcessOutputRisk
What it detects
An issue was carried from one planning period to the next (sprint or PI changed) but the planning period label was not updated — reported in wrong period.
Detection formula
IF issue resolved_in(period_actual) != label_period(period_planned) AND label_period not updated THEN FLAG period_hops = COUNT(distinct periods issue was sprint-assigned before resolution)Examples in practice
- A team shows an issue was carried from one planning period to the next (sprint or pi changed) but the planning period label was not updated during analysis.
- Example signal: An issue was carried from one planning period to the next (sprint or PI changed) but the planning period label was not updated — reported in wrong period.
Suggested response
Unblock pre-release and carry-over items with clear ownership and planning labels.
Coaching playbook
Symptom
An issue was carried from one planning period to the next (sprint or PI changed) but the planning period label was not updated — reported in wrong period.
Why it matters
When "Planning Period Carryover Without Label Update" 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
Unblock pre-release and carry-over items with clear ownership and planning labels.
Facilitation questions
- What system change would stop "Planning Period Carryover Without Label Update" 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.