Jira Workflows
State | Description |
|---|---|
Backlog | A ticket is in a backlog state before it is ready to be worked on. During it’s time in this state a ticket should be reviewed and updated with all the relevant information required to do the work. It is possible that subtask will be created while this is happening. |
To Do | The ticket is ready to be worked on, but nobody has started the ticket yet. It is possible to move tickets from To Do back to backlog if at any point new information is required. |
Cancelled | If during the process of reviewing and updating tickets on the backlog, the team agrees that a piece of work is not required, the cancelled state can be used. Ideally, once cancelled, a ticket should never make it back into the backlog. If the same issue returns, a new ticket should be opened and the old ticket referenced if required. |
In Progress | Work has begun. At this point, the ticket must be assigned to the team member working on it. |
Blocked | If at some point it becomes impossible to continue with the piece of work, the state should be changed to blocked. When changing the state it is required to leave a blocked comment. This should describe the nature of the issue. Blocked issues should be assigned to the scrum master to assess and rectify. |
In Review | This indicates that the assigned team member believes the work to be complete. At this point, local testing of the work should have been complete to a satisfactory level. Tickets reaching review should be assigned to the product owner, who will either conduct the review or assign the review to the appropriate person. It is possible to skip a review stage for tasks that don’t require confirmation from stakeholders. Software upgrades for externally produced products, for example. |
Testing | Ideally, any work we complete will be tested in a real world system before being officially released into production environments. This might include a long period of observation or some targeted testing by a particular member of the team. It is possible to skip a testing stage for tasks that don’t require real world testing and have no risk if something goes wrong. Data corrections for example. |
Ready for Release | It might be appropriate for groups of tickets to be released in conjunction with each other so this state allows a piece of work to take a pause while it waits to be released. This state indicates that all required work, review and testing have been successfully carried out, the definition of done and acceptance criteria have been met, and the end product is ready for production. |
Done | The deed is done, your quest successful. Bugs stemming from done tickets should be their own ticket, which references the original if required. Done tickets may be periodically cleaned out, so any critical information should be decanted to Confluence or a README |