We’re here to show you how JIRA workflow can be used for an Agile based project (for a pretty big team).

Of course, it’s subjective to each project, but this is one example that proved to be working quite nicely.

We’ll present in detail each step of the process, but we promise not to bore you.

Ticket status explained:

Submitted: All the tickets we create end up with this status, placed in the backlog.

To Do: We selected the tickets in the current sprint but haven’t started working on them yet.

*Note: You might not need both Submitted and To Do. 

On some projects, we use the Submitted to indicate that the tickets were submitted but not reviewed (yet). Once we review the ticket, we mark it in the To Do state.

In Progress:

  • Once a developer starts working on a ticket, they move the ticket to In Progress – here, they’re required to add the Sprint field (if it wasn’t already added).
  • Don’t start working on a ticket that isn’t in the current sprint unless the product owner instructs you to do so.

Code Review:

  • This is used once the ticket is implemented. 

Blocked:

  • As a developer: you want to start working on a ticket, but you’re blocked by other tickets. If that’s the case, you must link the ticket(s) blocking you and mention it in the comments.
  • As a QA: you can’t test something because a bug is blocking you. In this case, leave a comment saying why you’re moving the ticket to blocked.

RFQA:

  • Place a ticket in RFQA when it’s ready to be tested. This means there is an existing MR with the code fix (or the code fix is already deployed on develop branch).

Rework Needed:

Once a ticket is in RFQA, it can be re-opened if the fix doesn’t work. You reopen it by following these instructions:

1. Use the @ sign to inform the developer you’re reopening the ticket.

2. Include the reason why you’re doing it, with video/screenshot proof.

3. Change the state of the ticket 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 you tested but cannot close yet because of tickets that need to be fixed in the current sprint.

Waiting for Merge:

  • This status is used for tickets tested by the QA on a specific branch. Now we wait for the branch to be merged into the develop branch, so we can test it again and see if it works properly.

Closed:

  • This status is used when the ticket was fixed, implemented, or if it became deprecated / is no longer valid.
  • If the ticket was fixed, and you’re closing it – add video/screenshot proof and the reason why you’re closing it.

 Notes:

  • Related to the blocked state – don’t just move a ticket into blocked if you’re 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 using the Close option.

Closing a story:

We can close a story if:

  • all linked bugs got fixed;  
  • all remaining open are low priority and/or not added in this sprint (after the product owner has reviewed them); 
  • tickets were reviewed and not considered fixed in the current sprint.

Ad-hoc work/testing:

  • Check the Testing, Rework Needed, Blocked, and Code Review columns to see if we need to ping somebody or transition tickets into other states.
  • Make a filter with all the nonclosed project-related tickets and validate them again to see if we need to either update or close them.
  • Once we validate them, we should add a label like novValidated (which stands for November validated).

*Make sure to add the labels, links, or comments properly.

  • While doing this, you might find other bugs while validating the old ones.

If you want to know more about JIRA workflow and our services, let’s meet here:

https://calendly.com/betterqa