MI-01
Same-Timestamp Bulk Closure — Single Project
Metric Integrity
Default severity: medium
MetricsQualityRisk
What it detects
Multiple issues within one project were transitioned to a Done status at the exact same timestamp — statistically impossible as organic delivery. Bulk admin script or mass transition. done_transitions = changelog.filter(field=\'status\', new IN config.workflow.done_statuses)
Detection formula
FOR each_timestamp_group (precision = config.mi.timestamp_precision_seconds): // default: 1s IF COUNT(group) >= config.mi.bulk_closure_min_count // default: 3 THEN FLAG IF COUNT >= config.mi.bulk_closure_critical_count // default: 10 THEN CRITICALExamples in practice
- 46 features at 10:42:00 exactly — one squad
- 46 features transition to Done at exactly 10:42:00 — one squad, same second.
- Multiple issues share an identical resolved timestamp, indicating bulk admin action.
Suggested response
Audit closure and field patterns so metrics reflect real completion, not bulk admin updates.
Coaching playbook
Symptom
Multiple issues within one project were transitioned to a Done status at the exact same timestamp — statistically impossible as organic delivery. Bulk admin script or mass transition. done_transitions = changelog.filter(field=\'status\', new IN config.workflow.done_statuses)
Why it matters
When "Same-Timestamp Bulk Closure — Single Project" 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 "Same-Timestamp Bulk Closure — Single Project" 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.