The problem: Done column ≠ quality done

Low-quality deliverables appear when shipping means "merged" or "deployed" without clear acceptance. Under pressure teams skip review, manual test stays incomplete, and stakeholders become the first real QA after launch.

This is not technical-only—documents, design handoffs, and data deliverables need gates too. When only engineering gates exist and legal PDFs ship without reviewers, the same rework pattern repeats.

Sprint-end pressure bypasses gates—once, twice, a third time becomes culture. Then every release brings hotfixes and PMs ask "why didn't QA catch it?"—because QA was a downstream department, not a gate in flow.

Symptoms and costs

Symptom	Cost
Hotfix after every release	Instability
Rework eating capacity (team-estimated)	Throughput loss
"Just this once" review skip	Habit
Inconsistent style or format	Maintenance
Rubber-stamp approval	False green
Reject without actionable comment	Lost learning

Low quality compounds—each shortcut taxes the next change. Technical debt from skipped gates often costs more than "speed saved."

Framework: Define → Gate → Learn

1. Define — DoD and standards

Definition of Done per work type:

Code: tests, review, standards
Docs: reviewer, accuracy check
Design: accessibility checklist

Coding standards for dev work—visible in the project, not buried wiki. Vague DoD ("works") makes rubber-stamps inevitable.

2. Gate — approval and review

Task approval / quality gate:

submit_for_review before Done
Approver ≠ author
Reject with actionable comments

PR review linked to tasks—bottlenecks visible. Gates without authority are theater.

3. Learn — retro on defects

Root cause: skipped gate or weak spec?
Update DoD—not blame individuals
Track repeat failure modes in retro

PM responsibilities

Protect review time in the sprint—not the first cut.

Testable acceptance criteria—vague "works" fails.

Escalate systemic skips—patterns to leadership with trend data.

Where WKFGo helps

WKFGo provides task approvals, MCP get_coding_standards, git integration for PR/commit links, and submit_for_review workflows. It does not replace human judgment with automated test runners alone.

Desk tickets close the loop on production defects—prod bug → ticket → regression task → DoD update.

Workflow: task In Progress → submit_for_review → approver checklist → Done or reject with reason → PR link visible on task.

Quality signals without invented benchmarks

Instead of generic "defect rate 0.5 percent" claims, track:

Hotfixes per release (team-counted)
Approval reject reason categories
Time in review column (aging)

Trend matters more than industry averages you cannot verify.

Reviewer load balancing

If one senior takes every review—you built a new bottleneck. Rotate reviewers plus standards docs scale quality. WIP limits on the review column make bottlenecks visible.

Gates for non-software deliverables

Design PDFs, legal memos, data exports—same approval pattern:

Checklist acceptance
Reviewer ≠ author
Reject with comment

Consistent quality means universal gates—not code only.

Definition of Done workshop

Once per quarter the team reviews DoD—add one item from last quarter's defects. Participatory DoD beats PM-imposed lists for compliance.

Review WIP limits

If review column aging rises—limit WIP upstream (In Progress). Quality gates fail when queues are infinite. PMs should see review aging in sprint planning.

Common scenario: "just this once merge without review"

Release tomorrow; senior out sick; junior merges—verbal OK. Production: payment bug. Weekend hotfix. Retro: gate skipped—not "bad junior."

Fix: mandatory submit_for_review for user-facing work; backup approver in vacation policy; track reject reason categories.

Acceptance criteria checklist

Testable—pass/fail observable
Reviewer assigned before start
Standards link on task
PR linked before Done

Anti-patterns

QA as the only quality owner
Done without reviewer
Unread standards docs
Velocity bonuses without quality signals
Reject without comment

Getting started this week

Update DoD checklist for one work type—add one quality item from the last release retro. Assign approver roles in project settings—ambiguous approvers mean skipped gates.

Frequently Asked Questions

Do gates slow delivery?

Often yes—hotfixes and trust damage cost more. Limit WIP on review queues so approver bottlenecks stay visible. If review is always skipped, the issue is culture—not gate design.

Non-code deliverables?

Same gate: checklist plus approver role. Legal and design deliverables create rework too without gates.

Standards enforcement?

Automate lint; keep judgment in review. MCP coding standards align reviewers—they do not replace humans.

Small teams without dedicated QA?

Peer review plus checklist minimum—still gate. Even pairs suffer from rubber-stamp Done columns.

Summary

Quality gates live in delivery flow—DoD, approvals, standards, PR links. Speed without gates becomes hotfix tax. Track hotfix trends without invented benchmarks. Review WIP limits matter as much as dev WIP limits.

Start now

Last hotfix: was a gate skipped? Add one approval rule next sprint for user-facing work.