Board Design: Flow Engineering

Our current columns (Backlog → In Development → Needs Code Review → Staging → Preprod → Deployable) were designed for a process we're leaving behind — one where a developer finishes their part, pushes code through a series of environment-specific gates, and waits for manual promotion at each stage. That process has three problems:

1. Environment columns are not work states.

"Staging", "Preprod", and "Deployable" describe where the code is, not what the team is doing. Moving a card from Staging to Preprod isn't work — it's a deployment artifact. With CI/CD, these promotions are automated. Giving them columns creates busywork (moving cards through stages where no human action happens) and hides the real question: is this feature on for users?

2. Hidden queues.

The board doesn't distinguish between "someone is actively reviewing this" and "this has been sitting in Needs Code Review for 5 days." A ticket in any column could be actively worked on or idle. This makes bottlenecks invisible.

3. No WIP limits.

Six columns with no WIP discipline means tickets spread across every stage. Developers start new work while their previous tickets sit in Needs Code Review. The board looks like progress — tickets in every column! — but throughput is low because nothing is finishing.

Column Definitions

Why only 5 columns?

Because there are only 5 meaningful states a ticket can be in:

1. Waiting to be started (Backlog)
2. Being built (In Development)
3. Being validated (In Review — in the preview environment)
4. Deployed but not yet released (Flagged — behind feature flag in production)
5. Released to users (Live)

Everything else — CI running, auto-deploy to staging, auto-deploy to prod — is automation. Automation doesn't get a column because no human is doing work during those steps. Giving automation a column creates the illusion of progress while actually just adding card-moving overhead.

Backlog

Standard prioritized queue. No WIP limit because this is the intake buffer. The discipline here is refinement — tickets entering the backlog should be ready to pull (clear acceptance criteria, sized, dependencies identified).

In Development

This is where the team builds. The WIP limit is calculated per pod based on composition.

This comes from DeGrandis' baseline of team_size / 2, which encourages pairing and prevents everyone from working on separate things simultaneously. The goal is: at least half the engineering capacity is collaborating on existing work, not starting new work.

How it applies to different pod compositions

Who counts as E?

What "done" means here: A PR exists, the preview environment is live, unit tests pass, the code compiles. The developer isn't "throwing it over the wall" — they're signaling that the ticket is ready for the team to validate together.

In Review

This is the most important column in the new board. It replaces three old stages (QA, UAT, signoff) with one: team validates in the preview environment.

What happens here:

• QA testing against the preview environment
• UAT / functional acceptance
• Visual/UI review
• Performance spot-checks if relevant
• Code review on the PR

All of this is done by the same team, not handed off to a separate QA team or UAT team. The person who built it is available to answer questions. The person reviewing has context because they've been involved (pairing, standups, shared ownership).

In practice, R is usually the full pod minus PM (devs + QA + SDET + designer), so Review WIP is roughly ceil(pod_reviewers / 2). But since reviews should be fast (same-day), this limit is mostly a safety valve.

How it applies

Cap at 3. Even if the formula gives you 4, cap Review WIP at 3. Beyond that, reviews are competing for attention and taking longer.

What triggers the exit: All checks pass, PR is approved and merged. At this point, CI/CD takes over — automated deploy to staging, preprod, and production behind a feature flag. No human action needed. The card moves to Flagged automatically.

Flagged (No WIP Limit)

This column is diagnostic, not active. No one is doing work here — the code is already in production behind a feature flag. This column exists to make a specific question visible:

If this column grows, it surfaces a problem:

• Product hasn't decided to release — prioritization issue
• Waiting for a coordinated launch — dependency issue
• Fear of turning it on — confidence issue (testing was insufficient)
• Forgot about it — process issue

Each of those is a different conversation, but they're all invisible if you don't have this column. The code is deployed, the developer moved on, and nobody notices that value is sitting behind a flag for 3 weeks.

Key metric: Flag-to-Live time. Track how long tickets sit in Flagged. If the average exceeds 3 days, investigate why.

Live

The ticket is done. Feature flag is ON. Users have it. Celebrate and move on.

When do tickets leave the board? Configure a rolling board filter to only show tickets that moved to Live in the last 7 days. Older tickets disappear from the board view automatically but remain in "Done" status in Jira — they're still queryable, they just don't clutter the board. If you use sprints as a planning cadence, sprint close also archives completed tickets naturally. The Live column should feel like a "recently shipped" feed, not an ever-growing list.

Validation is collaborative, not a handoff

The In Review column intentionally merges functional testing, acceptance, visual review, and code review into a single collaborative step performed by the whole team in the preview environment. Validation happens alongside the person who built the work — not after they've declared it done and moved on. Keeping all validation in one column is what prevents hidden queues and back-and-forth handoffs.

Research bears this out: testing treated as a separate, downstream phase catches defects at a 25–40% rate. Teams that build quality in — through pairing, shared test scenarios, and continuous validation in a preview environment — remove 85%+ of defects before a formal "testing phase" would even begin (Capers Jones, across 13,000+ projects).

Signals that validation has drifted into inspection

When issues consistently pile up at the end of the flow, it's usually a signal that quality is being inspected rather than built in. Watch for these patterns:

• Issues are discovered at the end rather than during the build — surfacing as rework, not progress.
• Acceptance criteria get interpreted instead of verified — a sign the AC wasn't binary and testable to begin with.
• Work moves backward on the board (Review → Development) more than occasionally.
• Reviewers only see the work at the end, having had no involvement during refinement or the build.
• Validation waits on a single role, creating a queue where finished work sits idle.

Practices that keep validation in flow

1. Write binary, testable acceptance criteria

"Match the mocks" or "works well" can't be verified — only interpreted. Each AC item should be something anyone can confirm with a yes/no answer without guessing intent. Testable AC written upstream prevents most end-of-line surprises.

2. Verify your own work before In Review

The Definition of Done for entering In Review includes the owner checking the work against its acceptance criteria — with evidence: a ticked AC checklist, a short recording, or a walkthrough of the preview environment. Entering Review means "ready to validate together," not "ready for someone else to test first."

3. Involve reviewers early, not just at the end

Bring validation forward. Reviewing acceptance criteria during refinement, and writing test scenarios together at the start of development, means the same issues get caught earlier, cheaper, and without a bottleneck.

4. Validate together in the preview environment

Don't just read the diff. Pull the branch or open the preview environment and click through it with the author. This catches what diff-reading misses and turns a multi-day review round-trip into a 30-minute session.

Fewer stages, faster flow

Every column transition is overhead — card moving, status syncing, notifications, standup discussion — and every additional stage adds queue time without adding throughput (Little's Law). The board keeps only the columns where a human is actively doing something. Adding stages to inspect finished work creates exactly the hidden queues and wait states the board is designed to expose and remove.

WIP limits are the single most important element of this board. Everything else is column naming. WIP limits change behavior.

Why They Work (The Math)

Little's Law (proven, not theoretical):

Cycle Time = WIP / Throughput

If your team has a throughput of 2 tickets/week:

Context Switching Cost (Weinberg)

Gerald Weinberg's research on cognitive overhead:

At 5 concurrent tickets, a developer spends 75% of their time switching between them and 5% on each. WIP limits prevent this.

What Happens When WIP Is Full

When a column hits its WIP limit and a developer finishes their current work, they should not pull a new ticket from the backlog. Instead:

1. Help finish something downstream — review a PR, help with testing, pair on a stuck ticket
2. Unblock something — investigate a blocked item, resolve a dependency
3. Improve the system — write tests, refactor, update documentation

With this board, track four metrics (aligned with Mik Kersten's Flow Framework):

The first three are standard flow metrics. The fourth — Flag-to-Live time — is unique to teams with feature flags and is the new "hidden queue" to watch.