QA as a Separate Workflow State Breaks Flow

Many teams still model testing as a distinct workflow state.

Work moves from development into “QA.”
Stories wait until testing capacity is available.
Validation happens after implementation is considered complete.

This structure is usually justified in the name of quality.

In practice, it breaks flow.

A Separate QA State Creates a Queue

When QA is modeled as a separate workflow state, a queue is created by design.

Queues:

  • Increase work in progress

  • Delay feedback

  • Inflate cycle time

  • Hide risk until late

From a flow perspective, the transition into a QA state is not neutral.
It is a batching point.

As load increases, this queue becomes the dominant bottleneck—regardless of how capable the people are on either side.

Late Testing Delays the Only Signal That Matters

In flow-based systems, aging is a leading indicator.

It tells you when work has exceeded its expected time in progress and the system is losing control.

A separate QA state delays that signal.

Work appears “almost done” while risk accumulates downstream.
Aging is masked until testing finally begins—when options are already limited.

Late feedback forces explanation.
Early feedback enables correction.

Definition of Done Must Cross the State Boundary

Optimizing flow does not mean compromising quality.

It means changing where quality is addressed.

In a flow-optimized team:

  • The team owns work to a true Definition of Done

  • Testing happens continuously, not after a handoff

  • A story is either in progress or done—never “done except for QA”

Removing QA as a workflow state restores the integrity of WIP and aging signals.

Where QA Expertise Creates the Most Value

Eliminating QA as a workflow state does not eliminate the need for QA expertise.

It repositions it.

QA capability has the highest leverage when focused on:

  • Automated regression testing

  • Test strategy and coverage

  • Test data and environments

  • Quality gates in CI/CD pipelines

  • Non-functional testing patterns

This shifts QA from a downstream validation step to a system-level capability.

Automation Is a Flow Multiplier

Automated testing collapses feedback loops.

It:

  • Reduces variability

  • Increases effective capacity

  • Protects cycle-time expectations

  • Prevents aging breaches caused by validation delays

Crucially, it does this without increasing WIP.

That is the only kind of capacity increase that improves flow.

This Is Not Anti-Scrum

Scrum already assumes cross-functional teams and potentially shippable increments.

The problem is not Scrum.

The problem is how work is modeled inside the sprint.

In many teams, QA exists as a separate workflow state within the sprint timebox:

Development completes stories early in the sprint.
Work then waits in a “QA” column.
Validation happens later, when testing capacity becomes available.

Although this technically occurs “within the sprint,” it still creates a queue.

From a flow perspective, nothing important has changed.

Closing Thought

QA does not break flow.

QA as a separate workflow state does.

If you want predictable delivery, honest aging signals, and stable throughput:

Remove the state.
Keep the expertise.
Build quality into the flow.

Scroll to Top