CH-07
Summary Changed After Work Started
Content & History
Default severity: medium
Product BacklogProcessQuality
What it detects
Issue summary was changed more than the configured maximum number of times after the issue entered an active status. summary_changes_post_activation = changelog.filter(field=\'summary\', date > first_active_date)
Detection formula
IF COUNT(summary_changes_post_activation) >= config.content.max_summary_changes_active // default: 1 THEN FLAG IF COUNT >= config.content.critical_summary_changes // default: 3 THEN CRITICAL (identity instability)Examples in practice
- Set once at creation; minor edits only
- A team shows issue summary was changed more than the configured maximum number of times after the issue entered an active status while max summary changes active is set to 1.
- Example signal: Issue summary was changed more than the configured maximum number of times after the issue entered an active status.
Suggested response
Protect narrative quality: write items before work starts and avoid late or empty edits.
Coaching playbook
Symptom
Issue summary was changed more than the configured maximum number of times after the issue entered an active status. summary_changes_post_activation = changelog.filter(field=\'summary\', date > first_active_date)
Why it matters
When "Summary Changed After Work Started" 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 "Summary Changed After Work Started" 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.