Review

• This is the first status of the workflow, which will be given to a new card (issue) that could contain a new feature or a bug related to an existing feature (card).
• Under this status, all new cards (issues) will be assigned to the concerned person who will review and update the status accordingly.
• The concerned person will verify that the task has proper
  1. Background
  2. Requirement
  3. Acceptance Criteria (Definition of Done)
• Whenever a Bug/Enhancement card is created, it should be added as a dependency to its existing card.
• A review is required by IT Team:
  • Perform analysis, research, and discussions.

To Do

• Once the status of the card (issue) is changed to “TODO“, this means the same card can be included in the sprint and can be assigned to a developer.
• All cards in “ TO DO “ will be assigned to developers during weekly sprint planning.
• Whenever a card is assigned to a developer with a “TODO“ status, assigning person must add “Time estimation“ to evaluate the timeline

In Progress

• This status indicates the developer is working on the card (issue).
• Once developers will start working on the “TODO“ card, they must change the status to “INPROGRESS“ add a “Due Date” to that card.

Code Review

• The purpose of this status is to maintain the quality of code by engaging another developer to review the code.
• Once a developer has completed the coding part of “In Progress“ cards, they can update the status to “Code Review“.
• Developer should remove the “Due Date” from the card before moving the card to “Code Review” status.
• Then the same card will be assigned to a new developer for “Code Review”.
• On completion, the new developer will update the status to “Integration Testing“ and will assign the card to the QA person for manual QA.
• If the “Code Review” person finds some issue in the code, he/she will move the card back to the “To Do” section with a label “Code Review Rejected”.

Integration Testing

• The purpose of this status is to ensure quality during the development phase.
• The QA person will apply all related use cases on the live link and will remove bugs if found, so QA Team should not spend much time on “Staging UAT“ status.
• Once a QA person will find a bug, he/she will add the bugs in a comment and will move the ticket back to the “To Do” section with the “QA Rejected” label.
• QA person will add his/her “Due Date” to QA this card.

Done

• Once “Integration Testing“ for a card is done, the developer will change the status to “Done“.
• On closing the sprint all cards with “Done” status will be removed from the current sprint and all other pending (“To Do”, “In progress“, etc.) cards will be bumped to the newsprint or backlog.

Staging UAT

• Once a card is in Staging UAT, then it should be assigned to someone from the IT team to perform the UAT.
• IT team members will add “Due Date” for Staging UAT for the assigned task.
• While doing Staging UAT, if the UAT person finds any bug, he will add a comment containing the issues found and move this card back to “To Do”.
• The purpose of this status is to do the manual User Acceptance Testing on the staging environment.
• UAT person will remove the Due Date from the card before changing its status to “Ready to Merge”.

Ready To Merge

• Once all the use cases are applied and all related/linked bugs (if any) are resolved, UAT person can change the status from “Staging UAT” to “Ready to Merge”
• This status indicates that cards can be merged into the production environment.
• Someone from the IT team will add the deployment label to the card for the preferable deployment day.

Deployment/Prod UAT

• Once a card is deployed on production and is ready for the Production UAT, “Deployed/Prod UAT” status will be updated.
• Once a ticket is deployed it should be smoke tested / verified within a couple of days of deployment and then moved to “Completed”.
• If Bugs are found during “Production UAT”, UAT person will create new bugs in Backlog with the “Review” status, if the bug can be catered standalone. Otherwise UAT person will inform Sahil to roll the change back and move the card back to “To Do” with “UAT Rejected” label.
• QA person will not change the status of “Production UAT” task unless all linked bugs are resolved.

Completed

• Once all the testing is done on Production level and all related bugs are resolved, card status will be changed to “Completed”.
• On closing the sprint all cards with “Completed” status will not be bumped to the next sprint.

Back Burner

• If an “Urgent Task or Production Bug Task” comes under priority, then the ongoing card(issue) is moved from “In Progress” to “Back Burner”.
• This status indicates the developer was working on the card (issue) and moved it from “In Progress”.
• A Card can also be moved to “Back Burner” from “In Progress”, if the developer faces some conflicts and it’s required some time by the IT team to answer.