Workflow Stages: How Many Do You Need?
A workflow stage is a segment of a path with a single owner — work enters it, one person or system is accountable for it while it's there, and it leaves when that owner's completion criteria are met. The number of stages a workflow needs equals the number of times ownership changes hands between trigger and completion. Not the number of activities performed, not the number of teams involved, and not the number of status updates anyone would like to see.
That single rule resolves most of the arguments teams have about board design. But it's worth working through why it holds, because the wrong answers are intuitive and the consequences of over-staging and under-staging are quite different problems.
The Rule: Stages Mark Transfers, Not Tasks
The question "how many stages?" almost always gets answered by listing activities: intake, research, draft, review, revise, approve, publish. Seven activities, seven columns. It feels rigorous, and it's usually wrong.
Consider that list with owners attached. If the same writer does research, draft, and revise with no handoff in between, those three activities are one stage — the work never left the writer's hands, and no one else's accountability began or ended. Splitting them creates three columns that only the writer touches, which means three status updates that exist purely as self-reporting, no clearer answer to "whose move is it?" (it was always the writer's), and three chances for the board to be wrong when someone forgets to drag a card.
Now consider the reverse case. Suppose "review" involves a peer reviewer and then, for regulated content, a compliance reviewer. That's one activity name covering two owners — which needs to be two stages, because the answer to "whose move is it?" is different in each, and work stalls invisibly whenever it's ambiguous.
The stage boundary is where accountability changes. Everything else is detail that belongs in fields, checklists, or subtasks — not in the path's structure.
Why the Intuitive Answers Fail
"One stage per activity." Produces boards that mirror a procedure document rather than a flow of responsibility. The cost is tracking overhead at every boundary and, more insidiously, data decay: when stage transitions don't correspond to anything meaningful, people update them late, in batches, or not at all — and the metrics computed from those timestamps become fiction. Stage data is only as good as the reason people have to keep it accurate.
"One stage per team." Produces the org chart again. It also encodes the ownerless-stage problem directly into the design: a stage owned by "Legal" has no one accountable while work sits in it. Teams staff stages; they don't own them.
"As many as we need for visibility." The most seductive wrong answer, because visibility is a legitimate goal. But stages are an expensive way to buy it. Each one costs a transition that someone must perform, and granular stages produce the illusion of precision — a card sitting in "In Review" for nine days looks precise and tells you nothing about why. Visibility is better bought with fields (status reason, blocked flag, due date), views, and aging indicators, all of which are cheaper and don't degrade when neglected.
What Over-Staging Costs
The symptoms are consistent and recognizable:
Cards that move through three columns in one afternoon, all by the same person
Stages nobody can define the entrance or exit criteria for
Transitions performed retroactively, in batches, before a status meeting
A board that has to be explained to new team members
Metrics that don't match reality, because the timestamps record when someone updated the board rather than when the work moved
The compounding problem is that over-staged workflows are usually abandoned rather than fixed. People stop maintaining a structure that costs more than it returns, and the board becomes a decorative artifact — at which point the team has neither structure nor visibility, and concludes that "workflow tools don't work here."
What Under-Staging Costs
The opposite error is less discussed and equally real. Its signature: a stage that everything sits in and nothing seems to leave.
A single "In Progress" column that contains work at five genuinely different states
Work that has clearly moved to someone else, with the board unchanged
Nobody able to answer "whose move is it?" without opening the item and reading the comments
Wait time invisible, because the queue between two people is inside a stage rather than between stages
Under-staging hides handoffs, which is precisely the thing workflow structure exists to expose. If two people work an item sequentially and the board shows one column, the interval between them — usually the largest wait in the whole path — is unmeasurable. It's not that the work isn't tracked; it's that the failure mode is structurally invisible.
The Working Range
For most knowledge-work paths, applying the ownership rule lands somewhere between three and seven stages. Not a target — an observation about how many times work typically changes hands before it's done.
Three to four covers most single-team workflows: intake, work, review, done. That's genuinely enough when one person does the work and one person reviews it.
Five to seven is typical for cross-functional paths — procurement with tiered approval, content with legal review, onboarding across departments — where several distinct owners each hold the item.
Beyond eight, check whether you're staging activities rather than transfers, or whether you're actually looking at two workflows chained together. Long paths often decompose cleanly into a primary workflow plus a distinct downstream one with its own trigger and completion — which is easier to run, measure, and improve than one very long path.
Below three is rarely a workflow at all. Two stages ("to do" and "done") describe a task list, which is fine if the work genuinely is individual, and inadequate the moment items pass between people.
A Test for Each Boundary
For any stage boundary you're considering, ask three questions:
Does accountability change here? If the same person owns the work on both sides, it's not a boundary.
Is there a completion condition someone could verify? If you can't state what must be true for work to leave this stage, the stage has no exit criteria and items will linger in it.
Would work ever wait here? A stage that work passes through instantly, without queuing, is recording a moment rather than holding work. Consider whether it's a field update instead.
A boundary that answers yes three times is real. Two out of three is worth keeping if the stage marks a handoff. One or zero means you've found a stage to merge.
When to Add a Stage Later
Stage counts should be revised as the workflow reveals itself, and there are two legitimate triggers for adding one.
The first: a handoff you didn't know about. Mapping or measurement reveals that work regularly passes to someone whose involvement wasn't in the design — an informal approver, a coordinator, a specialist consulted on certain item types. That transfer deserves a stage, because it's already happening invisibly.
The second: a wait you can't locate. If cycle time is long and no single stage's data explains it, the delay is likely inside a stage where two things are happening in sequence. Splitting it at the transfer point makes the wait measurable, which is the prerequisite for doing anything about it.
Both triggers share a shape: add a stage when reality has revealed a transfer that the structure doesn't reflect. Neither is "we'd like more detail in the report."
FAQ
How many stages should a workflow have? As many as it has ownership transitions between trigger and completion. In practice this lands at three to four for single-team paths and five to seven for cross-functional ones. More than eight usually means stages were drawn around activities instead of handoffs, or that two separate workflows have been chained into one.
What defines a workflow stage? A segment of the path with a single accountable owner and a verifiable completion condition. Work enters, one owner is responsible while it's there, and it leaves when that owner's exit criteria are met. Stages mark where responsibility transfers, not where activities differ.
Is it better to have too many or too few stages? They fail differently. Too many produces tracking overhead and unreliable data, and often ends in the board being abandoned. Too few hides handoffs and makes the largest waits unmeasurable. Under-staging is more common in newer workflows; over-staging in ones that have been "improved" several times.
Should each team have its own stage? No. Teams staff stages; individuals or specific roles own them. A stage assigned to a department reproduces the ownerless-stage problem, where work sits with no one accountable. If two teams touch an item sequentially, that's two stages, each with a named owner.
Can a workflow have too much structure? Yes, and the cost is usually abandonment rather than inefficiency. Structure that costs more to maintain than it returns in clarity gets neglected, leaving the team with a stale board and no visibility. The corrective is to add structure as reality demands it rather than designing it in advance.
