TQ-22

Acceptance Criteria Read as Definition of Done

Text Quality

Default severity: high
ProcessMetrics

What it detects

Acceptance criteria list DoD/process steps (code review, deploy, QA sign-off) instead of user-visible behavior (~9% of AC).

Detection formula

IF AC matches DoD keyword patterns without observable user outcome THEN FLAG

Examples in practice

  • AC: code review done, merged to main, deployed to prod.

Suggested response

Move process checks to team DoD; keep AC outcome-focused and testable.

Coaching playbook

Symptom

Acceptance criteria list DoD/process steps (code review, deploy, QA sign-off) instead of user-visible behavior (~9% of AC).

Why it matters

When "Acceptance Criteria Read as Definition of Done" 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

Move process checks to team DoD; keep AC outcome-focused and testable.

Facilitation questions

  • What system change would stop "Acceptance Criteria Read as Definition of Done" 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.

Product tourSign in
TQ-22: Acceptance Criteria Read as Definition of Done — FlowAnalyzer