TQ-25

Acceptance Criteria State Benefits Not Verifiable Conditions

Text Quality

Default severity: high
ProcessMetrics

What it detects

Acceptance criteria mix business benefits or outcomes with technical design instead of verifiable conditions.

Detection formula

IF AC matches benefit/value cues without observable/GWT patterns THEN FLAG

Examples in practice

  • AC bullets list prínosy and REST implementation with no testable behavior.

Suggested response

Rewrite each AC as Given/When/Then or observable user checks; keep benefits in description or value statement.

Coaching playbook

Symptom

Acceptance criteria mix business benefits or outcomes with technical design instead of verifiable conditions.

Why it matters

When "Acceptance Criteria State Benefits Not Verifiable Conditions" 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

Rewrite each AC as Given/When/Then or observable user checks; keep benefits in description or value statement.

Facilitation questions

  • What system change would stop "Acceptance Criteria State Benefits Not Verifiable Conditions" 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-25: Acceptance Criteria State Benefits Not Verifiable Conditions — FlowAnalyzer