MI-02
Same-Timestamp Bulk Closure — Cross-Project
Metric Integrity
Default severity: medium
MetricsQualityRisk
What it detects
Identical bulk closure timestamp appears across the configured minimum number of projects simultaneously — portfolio-level admin action requiring governance review.
Detection formula
IF MI-01 event timestamp matches across >= config.mi.cross_project_min_projects // default: 2 projects THEN ESCALATE to governance level Record: all affected projects, total issue count, actor if availableExamples in practice
- 58 features across Team A + Team B at same second — portfolio-level admin
- 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
Identical bulk closure timestamp appears across the configured minimum number of projects simultaneously — portfolio-level admin action requiring governance review.
Why it matters
When "Same-Timestamp Bulk Closure — Cross-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 — Cross-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.