MI-06
Sprint Assigned After Resolution
Metric Integrity
Default severity: medium
MetricsQualityRisk
What it detects
An issue was assigned to a sprint after it was already in a Done status, or assigned to a sprint starting after the resolution date.
Detection formula
IF sprint_assignment_date > resolution_date THEN FLAG IF assigned_sprint.start_date > resolution_date THEN CRITICALExamples in practice
- Item resolved then added to a future sprint — sprint data corrupted
- 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
An issue was assigned to a sprint after it was already in a Done status, or assigned to a sprint starting after the resolution date.
Why it matters
When "Sprint Assigned After Resolution" 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 "Sprint Assigned After Resolution" 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.