Making "done" mean something in Jira
How to move your definition of done out of a wiki page and into the Jira workflow itself, using status categories, transition conditions and validators rather than hope.
Your Done column contains three things that are not done. One is merged but not released. One is released but the flag is off. One was moved because the sprint was ending. Everyone knows this, everyone has stopped trusting the column, and the definition of done is a wiki page that was last edited eighteen months ago by somebody who has left.
The problem is not that people are careless. It is that Jira lets any status be reached by anybody at any time, and your definition of done lives somewhere Jira cannot read. Fix the second thing and the first stops mattering.
What Jira already does, and what most teams never touch
Jira’s workflow engine is considerably more capable than the way most organisations use it.
Statuses belong to status categories. Every status you create maps to one of three categories: to do, in progress, or done. This is the detail that changes how you should design. Boards, burndowns and most reporting read the category, not the name. That means you can have several distinct statuses that all count as finished for reporting purposes, and several that do not, without breaking any chart. You are not limited to one column called Done.
Use that. The single most valuable change most teams can make is to split the end of the workflow in two: one status meaning the change is merged and on the main line, another meaning it is live for users. Put the first in the in-progress category and the second in done, and your burndown suddenly stops lying about the last three days of the sprint.
Transitions carry conditions, validators and post-functions. These are three different things and the distinction matters.
A condition controls whether the transition is even offered. Use it for who: only the assignee, only someone in a given role.
A validator runs when someone attempts the transition and blocks it with a message if the check fails. This is where your definition of done belongs. If a fact must be true before something is done, a validator is the place that fact gets checked, at the moment of the claim, in front of the person making it.
A post-function runs after the transition succeeds. Use it for consequences: stamping a field, updating a parent, firing a webhook.
Transition screens. A transition can present a screen requiring fields to be filled. Blunt, effective, and available in every Jira I have worked in.
The development panel. If your repositories are linked, Jira knows about branches, pull requests and builds against an issue. That information is available to automation rules, which means “has a merged pull request” is a condition you can act on rather than a question you have to ask.
Writing a definition of done a workflow can check
The exercise is to convert every line of your wiki page into a statement that is either mechanically checkable or explicitly not.
“Code reviewed” is checkable, because the development panel knows whether an approved pull request exists. “Tested” is not, unless you decide what evidence counts. “Documentation updated” is not checkable at all, but “the documentation field is populated or explicitly marked not applicable” is, and it forces the same conversation in a tenth of the time.
Sort your list into three buckets: facts Jira already holds, facts Jira could hold if someone recorded them, and judgements. Enforce the first with validators, capture the second with a required field on the transition screen, and leave the third to a human. A definition of done with four enforced items and two honest judgements beats fourteen aspirational bullets nobody reads.
Be aware of one limit. Jira’s built-in validator set is deliberately small, mostly around field presence, modification and permission. Anything richer, such as “a linked issue must be in a given state” or “this custom field must match that one”, typically needs a workflow app or an automation rule that reverses the bad transition and comments explaining why. Both work. The app is cleaner and costs money; the reversal is free and lands after the person has already claimed the work is finished, which is a materially weaker intervention.
Jira can only check what has been written into Jira
Jira can only check what has been written into Jira. A validator can confirm an approved pull request exists. It cannot confirm the pull request implements the ticket. The gap between “the artefacts of the process are present” and “the thing was actually built correctly” is not one the workflow engine can close, and pretending otherwise produces a very disciplined form of theatre.
Workflow changes are administrator work with blast radius. Workflow schemes are usually shared across projects. Adding a validator for one team can change behaviour for six others, and in a large instance the person who can make the change is not the person who wants it. Budget for that politically, not just technically.
After-the-fact reversal teaches people to route around it. If your enforcement is an automation rule that moves the issue back, the first thing a determined person does is move it forward again. Enforcement at the moment of the claim gets argued with; enforcement afterwards gets ignored.
Bulk transitions and sprint hygiene. End-of-sprint cleanup moves items in bulk, and validators are inconsistently applied depending on the path taken and the version. Test yours.
A ticket can be genuinely done and never merge anything. Investigations, decisions, vendor work. A workflow tuned entirely around development evidence punishes the work that has none, and people respond by opening fake tickets rather than by doing worse work.
Split the end of your workflow first
Split the end of your workflow. Merged and released as separate statuses, mapped to different categories. Free, takes an hour, and immediately makes the board honest about the last stretch of the sprint.
Rewrite the definition of done as checkable statements. Do this in a room with the team, not alone. The argument about which items are actually checkable is the valuable part.
Add validators for the two or three that Jira already holds. Start with fewer than you want to. Every validator is a place someone gets stuck at five o’clock on a Friday, and the cost of that is real.
Require the evidence field. For the items Jira could hold but does not, a required field on the transition to done is cruder than a validator and considerably better than a wiki page.
Then automate the release status. Have your deployment pipeline move the issue to released rather than a human. This is the piece that removes the most manual work, because “is it live” is the question people ask most often and the one nobody can answer.
Where this breaks down
More enforcement can produce worse data. Make the transition to done hard enough and people leave things in progress, or open a second ticket for the remainder. Your board gets cleaner and your picture of reality gets worse. Watch for a rising count of long-lived in-progress items after you tighten anything.
The definition of done is often a proxy for a trust problem. If the real issue is that a particular team ships things that break, a validator will not fix it and will be resented as an accusation delivered by tooling.
Splitting statuses breaks saved filters and dashboards. Anything filtering on the status name rather than the category will quietly return the wrong set. Search your instance for hard-coded status names before you change anything.
Some teams genuinely do not need this. A team of six shipping continuously, where everyone can see everything, gets very little from workflow enforcement and pays the friction anyway. This guide is aimed at organisations where the person asking “is it done” cannot simply walk over and look.