Signs your workflow has too many statuses

Someone finishes a piece of work and opens the status dropdown. The branch is pushed, the pull request is open, nobody has looked at it yet. Is that Ready for Review, In Review, or Awaiting QA? They read the three options twice, pick the middle one because it is the middle one, and move on.

That is where the board becomes fiction, and it is how a workflow with too many statuses actually fails — not loudly. The card is in a plausible column, standup goes fine, and a value has been entered that does not mean what the column says. The next person enters it differently, and a few weeks of that leaves an approximation everybody still reads as a fact.

A status has to change somebody's behaviour

The question is not whether the distinction is real. Almost every distinction is real: code that is written but unreviewed is genuinely in a different condition from code sitting in a reviewer's queue. The question is whether anybody behaves differently once a task enters the state. Someone gets notified, something joins a queue, a person knows the work is now theirs.

If nothing changes, the state records a precision nobody acts on, and that is not free. Every state added multiplies the judgement calls a person makes while their attention is elsewhere, and judgement calls under time pressure get made inconsistently. The state buys nothing and spends accuracy. Nobody announces that they have stopped trusting the board; they start asking in chat, which is most of why nobody updates the board. The general form of this test is in what a five-person team actually needs.

Five signs of too many statuses

Two states nobody can reliably distinguish. Name a task, ask two people separately which of the two it is in, compare. If they disagree, or either has to reason it out loud, you do not have two states. You have one state with a coin flip attached.

A state only one person ever sets. Look at who moves work into each column. If exactly one person ever does, it is usually a private reminder that ended up in the workflow — invisible to everybody else, and still a decision everybody else has to skip past. That is a label, not a stage the whole team has to hold in their heads.

States that encode who is waiting rather than what is true. Waiting on Design. Waiting on Customer. Blocked by Ops. A stage says where work is in its life; these say whose inbox it is in. Put both in one field and the moment a task is in review and waiting on a customer, one of the two facts has to lose. An assignee plus a field carries both.

A Blocked state that hides why. The work is still somewhere specific, it just is not moving, and the useful content is the reason — which a Blocked column throws away. Jira, which nobody accuses of minimalism, models this as a flag rather than a status: a checkbox field called Flagged whose single value is Impediment, with Atlassian's instructions suggesting a comment "to indicate your reason" (support.atlassian.com). Blocked is an attribute laid over whatever stage the work is really in.

A column that is a graveyard. Things arrive and nothing leaves. If nothing has left a state in a month it is a bin rather than a stage, and it is worth saying which bin out loud: either rename it Won't do and close the tasks, or admit it is a backlog and treat it like one.

Some teams genuinely need more states

The advice this collapses into — cut back to three — is right more often than not, and still wrong for a recognisable class of team. If you have a real QA gate, with a person whose work starts when yours stops, that handoff needs a state, because the state is how they find out. Same for a release step someone signs off on, or a formal handoff between functions who do not sit together. There the state is the mechanism; delete it and the handoff happens by tap on the shoulder, when it happens at all.

Which is why "how many statuses should we have" has no numeric answer, in Jira or anywhere else. The defaults are worth knowing, though. A new team-managed Jira board is assigned the default statuses To do, In progress and Done (support.atlassian.com), and Atlassian calls the statuses that arrive with a template "recommended starting points" you can "edit or remove from a workflow to suit your team's need" (support.atlassian.com). Six states that each trigger something real beat four where two are ornamental.

How to simplify workflow states

Do this with the board open, one state at a time.

1. Say what changes when a task enters it. Who is notified, whose queue it joins, what stops, what starts. A real answer sounds like "Ana picks it up from here". "The code is written but not reviewed" is a description, not a behaviour.
2. Delete every state with no answer. Move its tasks to the closest neighbour. Nobody will notice, which is the point. Add one back only the second time you actually needed it.
3. Merge the pairs people cannot tell apart, keeping whichever name the team already says aloud.
4. Prefer a field when you are recording an attribute rather than a stage. Blocked, needs design, waiting on a customer, customer-reported, risky — all true while work sits in some stage. Fields combine; states do not. This is what lets you cut states without losing anything, because most of what bloats a workflow is attribute data filed as stages.

Then recite the list, in order, from memory, a week later. If you cannot, it is still too long.

Where the tool comes in

A new board in Kevta arrives with five stages — To Do, In Progress, In Review, Ready for QA, Done — and with Title, Assignees, Status, Priority and Due Date already on it (how boards work). So the shortest path is not designing a workflow at all: file issues against the default, then delete whatever nobody acts on. Our own default ships a QA state plenty of teams should remove in week one, and we would rather say that than pretend five is the right number for everybody.

The other side of that coin: Kevta has no workflow schemes. A status is a select column — you name the options and order them, and nothing enforces which may follow which. A team with a real gate has to model it with the fields available and trust people to respect it. There is no reporting layer either, so nothing aggregates how long work sat in a state. If you need enforced transitions, use something else.

The walk-through holds whatever you run it in. If you want to try it somewhere with fewer states to begin with, Kevta is in beta and there is a waitlist on the home page.