CH-12
Assignee Instability
Content & History
Default severity: medium
Product BacklogProcessQuality
What it detects
An issue was reassigned more than the configured threshold, or has more unique assignees than the configured maximum. assignee_changes = changelog.filter(field=\'assignee\') unique_assignees = COUNT(DISTINCT values IN assignee_changes)
Detection formula
IF COUNT(assignee_changes) >= config.content.assignee_change_warning // default: 3 THEN FLAG IF unique_assignees >= config.content.max_unique_assignees // default: 4 THEN FLAG knowledge_fragmentationExamples in practice
- Stable; 1–2 changes max
- A team shows an issue was reassigned more than the configured threshold, or has more unique assignees than the configured maximum while assignee change warning is set to 3.
- Example signal: An issue was reassigned more than the configured threshold, or has more unique assignees than the configured maximum.
Suggested response
Protect narrative quality: write items before work starts and avoid late or empty edits.
Coaching playbook
Symptom
An issue was reassigned more than the configured threshold, or has more unique assignees than the configured maximum. assignee_changes = changelog.filter(field=\'assignee\') unique_assignees = COUNT(DISTINCT values IN assignee_changes)
Why it matters
When "Assignee Instability" 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
Protect narrative quality: write items before work starts and avoid late or empty edits.
Facilitation questions
- What system change would stop "Assignee Instability" 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.