Defining task statuses that reflect actual work

Define task statuses around observable handoffs, not every project mood. A status should tell a colleague what has happened, who acts next and what evidence is needed to move on. If “in progress” covers active work, waiting for an answer and ready for review, it tells the team little. Ten subtle labels can then make updates harder than the work.

Map work before naming columns

Take a recently completed task and list the points where responsibility changed. Perhaps a request was clarified, assigned, produced, reviewed and accepted. Describe the entry and exit condition at each point.

“Ready” might mean the requested output and acceptance criteria are understood. “In review” might mean a specific reviewer has the actual deliverable. “Done” might require the review decision and final location.

Atlassian describes Jira workflows as statuses joined by transitions. Its documentation distinguishes a work item's status from priority and resolution. That distinction matters outside Jira too: “urgent” is priority, “waiting for the supplier” is a condition or status, and “duplicate request” is a closure reason. Mixing these meanings produces unreliable reports.

Jira Workflow Components Overview

Make waiting visible without creating a maze

Decide whether blocked work needs its own status or a flag and reason. A separate status is useful when the team reviews blocked items as a queue. A flag may be enough when the task remains owned by the same person and only needs a dependency noted. In either case, capture who can remove the block and when it will be revisited.

Avoid one status per department unless the handoff changes the next actor or service expectation. “With finance” can be a reviewer field if finance is one possible approver. If finance has a distinct queue with a formal decision, a separate gate may be justified. The rule is operational meaning, not visual neatness.

Define return paths

Review often sends work back; sketch the route from review to revision and back to review. A completion status should not be reachable before required acceptance. In Jira, transitions are configured in a direction; a path back requires a return transition. Test equivalent behaviour in the product actually used.

Use a concrete example: a designer submits a banner, the campaign owner requests a correction, and the revised file is reviewed. The task should show the current owner and which file was accepted. Merely moving a card to “done” after uploading version two can hide the absence of a second review.

Check whether the statuses help decisions

Ask a new team member to inspect ten items and identify the next action for each. If they need a chat message to understand several statuses, rewrite the definitions.

Monitor items that remain in a stage for unusually long periods, then ask whether they are genuinely waiting, neglected or misclassified. Maintain a short status glossary and revise it when actual work changes.