One Jira Column, Three Statuses: What Did the Board Just Hide?

Three cards sit in a Jira column called In Progress. One is being developed, one is waiting for review, and one needs approval from outside the team. The column isn't lying: all three are unfinished. It just isn't helping anyone see why they are unfinished.

More development won't clear the review queue, and a reviewer may have no authority to grant the external approval. In this illustrative board, a simple picture has grouped together work that needs different kinds of help.

That is the question I would bring to a board redesign: which distinctions would change the team's next conversation? A cleaner screen is welcome, but the point is to make the work easier to coordinate.

A status records the stage; a column shapes the view

A Jira workflow status describes the stage an item has reached. A board column can group one or more statuses. That gives teams flexibility: the workflow can retain a distinction without requiring every audience to see it as a separate column. [1][2]

For our three cards, the difference might look like this:

The proposed mapping hasn't added a new stage to the work. It has made existing stages visible. If the review status already exists, editing the workflow to add another one may be unnecessary.

This matters on shared Jira configurations. A display problem can sometimes be solved in the board rather than by changing a lifecycle that other teams, reports, or automations also use. The smaller change is preferable when it expresses the real need accurately.

Now return to the three cards

In the revised view, PAY-18 is visibly waiting for review. A developer who was about to start another task can see that finishing existing work may be a better use of attention. PAY-24 tells a different story: the team needs the external approver, not another developer.

The columns don't provide that capacity or decision. They reduce the reconstruction needed to ask for it. Instead of opening every card to discover what “In Progress” contains, the team can start with the relevant queue and discuss what would move it.

A separate column isn't always necessary. If two statuses lead to the same coordination response, grouping them may make the board easier to use. If a distinction never affects the conversation, it may belong in the card's details. The design should preserve differences people act on, rather than maximize or minimize the number of columns.

When the missing distinction is in the process

There is another possibility: the team has no shared meaning of “ready for review.” One person moves a card when coding finishes; another waits until supporting tests are attached. A separate Review column would make the disagreement visible, but it wouldn't settle it.

The people exchanging the work need to agree what the reviewer receives and what happens when the item is returned. Only then can a status represent a handoff that others understand. A configuration edit cannot create that agreement on their behalf.

Give completion the same care as waiting

The final column deserves particular attention because its mapping can affect how the board treats completion and relevant reporting. A column labeled Done does not establish that the workflow status, resolution, and every connected report mean the same thing. Check the behavior of the actual board against its documentation before interpreting a mapping change as better performance. [2]

Likewise, a card absent from the board is a different problem from a visible card in an unhelpful column. A filter or permission may exclude it before mapping becomes relevant. Moving columns around cannot recover a record the view never included.

After the change, I would watch the discussion around PAY-18 and PAY-24. Does review receive attention earlier? Does the approval request reach the right person? If neither moves, the board may have exposed a constraint that needs action elsewhere. That is still useful information, provided the team doesn't mistake a newly visible queue for a resolved one.

A good board lets these three unfinished cards remain three different problems. The team can then help each in the way it actually needs, instead of treating all unfinished work as a request to start more development.