How work enters, moves, and exits

Look at your team's project board. It tells you what tickets exist and what status they are in, but not where the work actually is.

A ticket marked "In Code Review" might have sat in someone's review queue for two days. A ticket marked "QA" might be waiting on a deploy window nobody on the team calls a deploy window. A ticket marked "In Progress" might be blocked because the design moved while the engineer was still building against the older version. None of this shows up on the board.

Most delivery-flow problems appear downstream of where they were caused. The slow cycle time, the QA pile-up, the missed sprint date. The cause is almost never at the stage where the symptom shows up; it is usually earlier, at how work entered the team and how much was let in at once.

Before optimizing any stage, draw what is really happening. Map first, intake second, the rest is hygiene.

Map the real path

One ticket. One walk. One afternoon. That is the size of the exercise.

1. Pick a ticket your team shipped in the last two weeks.
2. Sit down with the people who touched it. For every step, ask where it actually waited and for how long.
3. Write down the real pauses rather than the column the status sat in:
   • Hours in someone's review queue.
   • The day lost to a deploy freeze.
   • The week the design got redrawn.

The first time you run this, you will find shadow stages, places where work waits that the board does not show:

• Code review queues that no filter surfaces.
• Deploy windows that gate work without being labeled.
• Designs that get redrawn after a ticket is "in progress."
• QA that pauses on a Tuesday because of someone else's release.

The map also tells you whether to run a heavy process or a light one. A six-person team building a 0-to-1 app can run the whole flow on a single spreadsheet. A heavier ticket tracker would be overhead the team pays in clicks every day. A platform team with three squads and a phased Android rollout would collapse the same sheet inside a week. Calibrate by team size and information load.

Entry: one funnel, one artifact, a reservoir

This is where most of the real fix lives. The boundary between the rest of the company and engineering is where you decide what work actually is, and how much engineering takes on at a time.

Route intake through one source. Pick one team to own handover. In my setup that team is product. Growth, sales, customer support, and internal engineering work all notify product. Product is the only team that hands work over to engineering. The noise reduction is real, and once everyone gets used to the routing, it costs almost nothing.

Treat the handover as a document, the one engineering needs to start work. It contains:

• A spec or PRD.
• A design reference (a design file, a prototype, or a hand-drawn UI sketch in the AI era).
• The target release or sprint.
• A named engineer.

Engineering leads review the handover before it lands. Catching a problem at the handover costs an hour; catching the same problem after engineering has started costs days.

Put a reservoir between product and engineering. A backlog accepts whatever product adds to it. A reservoir is filled by product and pulled by engineering at the rate engineering can actually absorb. The constraint lives on the outflow rather than the inflow. (That is Goldratt's Theory of Constraints, ported from a factory floor to the intake boundary.)

Pulling a ticket out of the reservoir is a small ritual:

1. Take the next priority item.
2. Give it a high-level T-shirt size.
3. Name an engineer.
4. Decrement that engineer's available bandwidth (the output of the reserving-capacity exercise).

When the team's bandwidth is full, what is left in the reservoir is what did not fit. The overflow is the signal.

A recent example. Product on one of my teams stopped doing its gatekeeping job for a stretch. Tickets came in unfiltered, and engineering got buried. The quick patch had three moves:

• Pause the funnel.
• Reprioritize what was in flight.
• Share specific feedback with product about what broke.

The patch is reactive; recurrence is the predictable failure mode. Three mechanisms from Kanban practice catch the next funnel break early:

• Make the reservoir level public. When it grows past a threshold (number of items, or weeks of work at current pull rate), that triggers a review on its own.
• Run intake at a cadence. Weekly or biweekly, product and engineering leads compare what came in against what got pulled. A funnel break shows up as inflow outpacing outflow on the chart, which is the earliest signal available.
• Post per-class quotas inside the reservoir. Urgent, planned, internal each get a posted share. When a class exceeds its quota, the rule is a forced trade against another class. The trade routes the prioritization conversation back to product before engineering absorbs the cost.

A cost to expect. Product will sometimes call this waterfall, or call engineering slow. Tune around the pushback. The alternative, letting unfiltered volume through and hoping, costs the team more.

Transit: the fewest states that earn their keep

Once a ticket is moving, the temptation is to add states to track every sub-stage. Resist. Refuse every new state by default until a retrospective forces it through.

The bar is high:

• The work has to genuinely sit in that phase for a meaningful stretch (order of days).
• The existing states have to mislead someone reporting on them.
• No filter or automation can capture the same signal more cheaply.

An example that cleared the bar. On Android, a release ships as a phased rollout: the build reaches users gradually (10 percent, then 50, then 100) over the course of days. Before this team added a QA Done state, a ticket flipped to Done the moment QA approved the build. Most users still did not have it; the dashboard said "shipped" while production told a different story. QA Done earned its place because the wait was long and no other signal showed the actual rollout percentage.

A counterexample from a team I inherited. The workflow already had a Code Review Done, Deploy Pending state, meant to capture the wait between a merged PR and the next QA build. The wait is real, but it runs in hours and the build pipeline already shows it. Within a few weeks of watching the state in action, I could see it created more noise than help. People kept confusing it with the other in-flight states, so I removed it.

Each transition has a small set of operational preconditions:

• Backlog to In Progress: spec and design reference present.
• In Progress to Code Review: unit tests passing (where the team uses them).
• Code Review to QA: manual code review approved.
• QA Done to Done: rollout at 100 percent.

These are operational gates. Whether the thing is really done (feature shipped, outcome achieved, learning captured) is a separate question.

Guardrails fail in one specific way: theatre. Someone ticks the box without doing the underlying check, and the cost shows up later as a quality regression that the gate was supposed to catch. So audit the regression rate.

Multiple views

The project board is one view of the work. On a busy week I run at least three views in parallel:

• A dev plate filter (everything from Todo through Code Review).
• A QA plate filter.
• A release filter sliced by target version.

On smaller teams the same views collapse into a single spreadsheet. Pick the view that answers the question you are trying to answer this week.

The playbook is the artifact

The map, the funnel, the reservoir, the states, the views, the guardrails. All of it is under continuous edit; the place you edit it is the sprint retrospective.

When the same "you missed doing this" surfaces in retro two or three times, that is the signal to automate the step rather than repeat the reminder. Good automation candidates:

• Multi-board ticket creation.
• Cross-board field sync.
• Status linking.

Some process needs human judgment and stays manual. The retro tells you which is which.

The map produces a playbook. The playbook gets edited by the retro. The retro gets fed by the next map.