CH-10
High Field Churn
Content & History
Default severity: medium
Product BacklogProcessQuality
What it detects
Core fields were collectively changed more than the configured threshold after issue creation — the issue was redefined multiple times in-flight.
Detection formula
churn_fields = config.content.churn_tracked_fields // configurable list, default: \[description, AC, summary, story_points, assignee, parent, priority\] field_changes = COUNT(changelog WHERE field IN churn_fields AND date > created_at + config.content.churn_grace_hours) // default: 24h IF field_changes > config.content.field_churn_warning // default: 5 THEN FLAG IF field_changes > config.content.field_churn_critical // default: 10 THEN CRITICALExamples in practice
- A team shows core fields were collectively changed more than the configured threshold after issue creation while churn tracked fields is set to Configured per workspace.
- Example signal: Core fields were collectively changed more than the configured threshold after issue creation — the issue was redefined multiple times in-flight.
Suggested response
Protect narrative quality: write items before work starts and avoid late or empty edits.
Coaching playbook
Symptom
Core fields were collectively changed more than the configured threshold after issue creation — the issue was redefined multiple times in-flight.
Why it matters
When "High Field Churn" 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 "High Field Churn" 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.