Ticket Life Cycle

Ticket life cycle #

In a Scrum/Kanban board, tickets (or user stories, tasks, and bugs) typically move through various statuses that reflect their progress in the development lifecycle. Here’s a description of our ticket statuses and their meanings:

1. To Do #

  • Description: The ticket has been prioritized and selected for the current sprint but work has not yet started.
  • Typical Actions: Assignment to a team member during creation or sprint planning.

2. In Progress #

  • Description: Work on the ticket has begun/continued.
  • Typical Actions: Development, coding, initial implementation, and ongoing task updates.

3. Code Review #

  • Description: The ticket is awaiting peer review or code review.
  • Typical Actions: Review by another developer or team member, providing feedback, and making necessary adjustments.

4. QA Review #

  • Description: The ticket is in the testing phase, either in manual or automated testing.
  • Typical Actions: Execution of test cases, logging of any found defects, and verification of fixes.

5. Blocked #

  • Description: The ticket is blocked due to an external dependency, issue, or need for clarification.
  • Typical Actions: Identifying the blocker, communicating the issue, and seeking resolution.

6. Ready on Dev #

  • Description: The ticket is completed and ready to be deployed to a staging or production environment.
  • Typical Actions: Awaiting deployment process.

7. Ready on Staging #

  • Description: The ticket has been successfully deployed to the staging environment, tested, and accepted.
  • Typical Actions: Final verification, merging of code, and deployment.

8. Done #

  • Description: The ticket has been successfully deployed to the production environment. It is formally closed after all work and validation are complete.
  • Typical Actions: No further actions required unless reopened.

Workflow Example #

Here’s an example workflow for a ticket moving through these statuses on a Scrum/Kanban board:

  1. To Do: During sprint planning, the team selects the user story for the sprint and moves it to “To Do”.
  2. In Progress: A developer starts working on the user story, moving it to “In Progress”.
  3. Code Review: Once the developer completes the implementation, the ticket is moved to “Code Review” for code review.
  4. QA Review: After a successful review, the ticket moves to “QA Review” for QA validation.
  5. Blocked: If a dependency or issue arises during testing, the ticket is marked as “Blocked”.
  6. Ready on Dev: After successful validation on dev, the ticket status is updated to “Ready on Dev”.
  7. Ready on Staging: After successful validation on staging, the ticket status is updated to “Ready on Staging”.
  8. Done: Once post-deployment checks are successful, the ticket is marked as “Done.”

By clearly defining and using these statuses, the team can track the progress of each ticket efficiently, identify bottlenecks, and ensure smooth workflow throughout the sprint.