This post has been created to present how a good working JIRA workflow can be used for an Agile based project for a numerous team. Obviously, these are subjective to each project, but this is one example that proved to be working quite nice.

Firstly, I’ll just explain each status in particular, one by one:

Ticket status explained:

Submitted:

  • All tickets which get created end up with this status, placed in the backlog.

To Do:

  • Tickets which got selected in the current sprint, to be worked on but work didn’t start yet.

Note: You might not need both Submitted and To Do. On certain projects, we use the Submitted to indicate that these tickets were submitted but not yet reviewed. Once the ticket is reviewed and, probably work is ready to start on them, we can mark that ticket in the To Do state.

In Progress:

  • Once a developer starts to work on a ticket, he moves the ticket into In Progress – here, he is required to add the Sprint field, if the Sprint field is not yet added to the ticket. Do not start to work on a ticket that is not in the current sprint unless the product owner instructs you to do so.

Code Review:

  • Used once the ticket has been implemented but it is now in code review

Blocked:

  • As a developer, used if you started to work on this ticket but realized, or you are asked to work on this ticket but you are blocked by other tickets; if so, you must link the ticket which blocks you and mention this in the comment
  • As a QA, used if you can’t test this out due to another bug which blocks you from testing it; we need to leave a comment saying why we are moving the ticket to blocked;

RFQA:

  • Place a ticket in RFQA when it is ready for it to be tested. This means that there is an existing MR with the code fix, or if the code fix is already deployed on develop branch.

Rework Needed:

Once a ticket is in RFQA, it can be re-opened, as the fix didn’t work. Follow these instructions while reopening tickets:

1. When you reopen a ticket, you need to use the @ sign to inform the developer you are reopening it.

2. The comments need to have the reason why you are reopening it, with a video/screenshot proof. 

3. The state of the ticket needs to be moved to “Rework Needed”

4. The assignee of the ticket needs to be the developer who worked on it (and needs to fix it)

Tested:

  • Use the tested column to place stories which you tested but cannot close yet as there are tickets remaining to be fixed in the current sprint

Waiting for Merge:

  • This status is used for tickets which the QA tested on a specific branch; we are now waiting for the branch to be merged into develop branch, so we can test it again and see if it still works properly;

Closed:

  • This status should be used when the ticket has been fixed, implemented, or if the ticket became deprecated or is no longer valid;
  • If the ticket has been fixed, and you are closing it, also add a video or screenshot of proof. Also, the reason why we are closing it.


Notes:

  • Related to the blocked state, don’t just move a ticket into blocked if you are waiting for somebody to reply to a comment; instead, keep the ticket assigned to you, but address a comment to the person who needs to answer using the @ option. That other person will receive an email about it.

    If you didn’t receive a reply in 3 days or so, then you can do a ping and remind the person to reply to your comment as it is currently blocking you. Once this happens, you can move the ticket to the Blocked state, and assign the ticket to the person who needs to reply.
  • If a To Do ticket is not something you would like to see fixed, you can close it directly by using the Close option.

Closing a story:

We can close a story If all linked bugs (with is a bug) got fixed; or, all remaining open are low or lowest priority and/or not added in this sprint (after they have been reviewed by the product owner); if tickets are reviewed and not considered to be fixed in the current sprint, then we can still close the story.

Ad-hoc work/testing:

  • Check the Testing, Rework Needed, Blocked and Code Review columns first to see if we need to ping somebody or if we can transition tickets into other states
  • Make a filter with all of the nonclosed project-related tickets and validate them again, to see if we need to either update them or close them out
    • once we validate them, we should add a label like novValidated (which stands for November validated)
      • make sure to add the labels properly, links or comments (if nonexistent)
      • while doing this ad-hoc work, you might find other bugs while validating the old ones

That’s about it. Let me know if you found this useful!