MI-07

Planning Period Label Mismatch

Metric Integrity

Default severity: medium
MetricsQualityRisk

What it detects

Issue carries a planning period label (PI, quarter, release) that does not match the period derived from the actual resolution date. Label and period mapping are configurable.

Detection formula

planning_label_field = config.planning.pi_field resolved_period = derive_period(issue.resolutiondate, config.planning.period_calendar) IF field_value(planning_label_field) != resolved_period THEN FLAG Report: planned_period, actual_period, drift_periods

Examples in practice

  • Team B-1718 resolved Jan 2026, still labeled PI_LABEL_EXAMPLE
  • Bulk admin transitions or resolution anomalies distort cycle time and velocity metrics.
  • Closure timestamps or fields suggest data repair rather than organic delivery.

Suggested response

Audit closure and field patterns so metrics reflect real completion, not bulk admin updates.

Coaching playbook

Symptom

Issue carries a planning period label (PI, quarter, release) that does not match the period derived from the actual resolution date. Label and period mapping are configurable.

Why it matters

When "Planning Period Label Mismatch" 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

Audit closure and field patterns so metrics reflect real completion, not bulk admin updates.

Facilitation questions

  • What system change would stop "Planning Period Label Mismatch" 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.

Product tourSign in
MI-07: Planning Period Label Mismatch — FlowAnalyzer