Your Reports Believe the Category, Not the Status Name

A status named "Ready for SIT Deployment" was mapped to the Done status category.

Read the name again. It describes work that has not entered system integration testing, let alone UAT, let alone production. Three environments still ahead of it, and every report in the tool had already filed it as finished.

Two Fields, One of Which Nobody Reads

A Jira status has a name and a category. The name is written by whoever built the workflow, in the language of your process. The category is one of three fixed values — To Do, In Progress, Done — and it is what the tooling actually reads.

Humans read the name. Charts read the category.

Nobody sets that category as a decision. It gets chosen in passing when a status is created, or inherited from a template, or copied from a workflow somebody cloned two years ago because it was close enough. Then it becomes invisible plumbing: never displayed on a board, never reviewed in a retrospective, never mentioned in a single conversation about how the team works.

And it quietly redefines the most loaded word in delivery.

What Moves When the Category Is Wrong

Once an item reaches a Done-category status, a whole set of behaviours fire at once, none of which announce themselves.

The sprint burndown drops. Velocity counts the points. Roll-ups across epics and releases show the item complete. Every filter written with statusCategory = Done — and people write a lot of them, because it is more durable than listing status names — now includes work with a third of its lifecycle unspent.

Add the resolution field on top, which is a separate thing again. An issue can sit in a Done-category status with no resolution set, so one report calls it finished and another calls it unresolved, and both are reading the data correctly. That contradiction is usually the first symptom anyone notices, and it gets explained away as a quirk of the tool rather than a mapping error.

Meanwhile the team keeps working. SIT runs. Defects get raised. UAT happens. All of that effort lands on items the tooling wrote off weeks earlier, which means the most defect-dense part of the lifecycle produces no movement on any chart, because there is no movement left to make.

The Rule

The Done category is not a label for "we have finished our part." It is a claim about the whole item.

A status belongs in the Done category only when no activity still planned for that item can change its outcome.

That gives you a test you can apply to any status in ninety seconds. Ask what happens if the next environment rejects it. If the honest answer is that the item comes back — reopened, re-scoped, re-fixed, re-tested — then the item was not done, and any chart that said so was wrong before anyone opened it.

By that test, "ready for" anything is almost never Done. Ready is a handover, and a handover is the middle of a process, not the end of one.

Auditing It This Week

This is an hour of work and it does not need anyone's permission.

• List every status with its category, side by side. The names are what you have been discussing in stand-ups; the categories are what your reports have been computing. Put them in two columns and read across — the mismatches are usually obvious the moment they sit next to each other.
• Apply the reopen test to every Done-category status. For each one, name the activities that still happen afterwards. If testing, deployment or sign-off is on that list, the mapping is wrong regardless of how the status is named.
• Check the resolution alongside it. Done category with no resolution, or a resolution set on an item still in flight, both produce reports that disagree with each other and with reality.
• Then re-read one chart you have quoted to a stakeholder. Not to relitigate it. To find out what you were actually telling them.

That last step is the one that changes behaviour, because it turns a configuration detail into a specific sentence you said out loud in a meeting.

Why It Survives So Long

Because every individual signal looks fine.

The status name is accurate. The workflow diagram makes sense. The board looks right. The burndown descends smoothly, and a smooth descent is exactly what everyone is hoping to see, so nobody interrogates it. There is no spike, no error, no alert — the distortion is constant and consistent, which makes it indistinguishable from a healthy process.

There is also nobody whose job this is. Workflow configuration belongs to a Jira admin, reporting belongs to a delivery lead, and the definition of done belongs to the team. The category sits precisely at the intersection of all three, which in practice means it belongs to none of them.

For a QA lead there is a sharper reason to care. When work is marked finished before testing begins, every defect you find afterwards is a defect against something the organisation already considers shipped. That framing shapes how the finding is received, how urgently it is fixed, and how the effort is remembered — not because anyone decided it should, but because a category value chosen in passing decided it for everyone.

Open your workflow. Which statuses are in the Done category — and would any of them survive the reopen test?