What changed?
- 07/2026: Published a six-state reference workflow with entry and exit criteria.
- 07/2026: Added guidance for blocked work, review queues, and workflow metrics.
What is an issue tracking workflow?
An issue tracking workflow is the set of states and transition rules that describe how work moves from consideration to completion. A good issue tracking workflow makes the next action and current owner clear without requiring a status meeting.
A workflow state should describe a meaningful change in responsibility or decision. Avoid separate states for tiny internal steps that do not change what another person needs to know.
Product teams also need triage before the delivery workflow. Triage decides whether incoming work belongs in the backlog; the workflow then tracks accepted work.
Which issue statuses should a product team use?
Use the smallest set of issue statuses that changes ownership or action. Backlog, planned, in progress, review, done, and canceled cover the common product delivery path without hiding work inside ambiguous labels.
| Status | Meaning | Exit criterion |
|---|---|---|
| Backlog | Accepted for future consideration, not committed. | Priority and context justify a planning decision. |
| Planned | Committed to a cycle, milestone, or near-term plan. | An owner starts the work. |
| In progress | Someone is actively changing the product or validating the solution. | The change is ready for its required review. |
| Review | The change awaits code, design, product, or release review. | Required review passes or returns the issue to active work. |
| Done | The team met the issue definition of done. | Terminal state. |
| Canceled | The team deliberately stopped or invalidated the work. | Terminal state with a recorded reason. |
Why do issue statuses need entry and exit criteria?
Entry and exit criteria prevent two people from interpreting the same status differently. The criteria should state the required evidence, owner, or event that moves an issue into and out of each state.
- Planned requires an explicit commitment rather than high priority alone.
- In progress requires an active owner, not a future assignee.
- Review names the review type and reviewer when the distinction matters.
- Done names the exact completion event: merged, deployed, released, or validated.
- Canceled records why the team stopped the work.
Should blocked be an issue status?
Blocked should usually be a property or relation, not a permanent workflow status. An issue can remain in progress or planned while a blocker field names the dependency, owner, and next check date.
A blocked column often becomes a place where work disappears. If the team uses a blocked state, require a blocking reason, a responsible owner, and a visible review cadence.
Issue relations are useful when one issue cannot move until another issue is complete. The relation preserves the actual dependency instead of reducing it to a colored label.
Which metrics show whether an issue workflow works?
Cycle time, throughput, work in progress, state age, reopened issues, and review waiting time show whether an issue workflow moves predictably. Track trends by team and work type instead of using one target for every issue.
Cadylo provides configurable team workflows, lists, kanban boards, saved views, issue relations, cycles, and workspace analytics for flow and cycle time.
- Cycle time: elapsed time from active work to completion.
- Throughput: issues completed in a fixed period.
- Work in progress: issues in active states at one time.
- State age: time an issue has remained in its current state.
- Review waiting time: time ready work waits for required review.
Questions
Frequently asked questions about issue tracking.
How many issue statuses are too many?
A workflow has too many statuses when people cannot explain the difference between adjacent states or when a transition does not change ownership, evidence, or next action. Small product teams should start with five active states or fewer and add one only after repeated ambiguity.
Is a backlog an issue status or a separate list?
A backlog can be a workflow status, while saved views and filters create separate lists for teams, priorities, projects, or planning horizons. The important distinction is that backlog means accepted but not committed.
When is an issue done?
An issue is done when it meets the team definition of done stated for that work type. For a software change, that may mean merged, deployed, released, or validated; the team should name the exact event instead of relying on an implicit convention.
How often should a team change its issue workflow?
Change an issue workflow after repeated evidence that a state hides ownership or prevents a useful decision. Review workflow data monthly or quarterly, but avoid changing state definitions during every difficult project.