[QUT] Ticket Lifecycle
This is a conceptual model of a ticket's lifecycle, which could be useful when building workflows or generating reports. It looks like a waterfall, but it's different. Honest. 🌊
Three (non-terminal) phases: development, QA, release.
Each split into two stages (inactive/active), with two states (unassigned/assigned). The active-unassigned state doesn't make sense, so it's not included.
- Reported – the backlog; distinct from "ready" because the team lead hasn't moved it into the currently-active scope yet
- Development
- Ready – any developer can pick up these items
- Queued – assigned to a developer, not currently in progress
- In progress – analysis, development, underpinning Service Requests, etc.
- QA
- ready for QA – any tester can pick up these items
- queued for QA – assigned to a tester, not currently in progress
- QA – undergoing testing/QA; includes code review, user acceptance testing, etc.
- Release –
- ready for release – any operator can pick up these items
- queued for release – assigned to an operator, not currently in progress
- release – being released; includes the whole SCMG/CAB process
- Closed –
Some Observations
Ideally, any time a ticket moves to a different phase it should be de-assigned, so it can be picked up by a member of the team responsible for that phase. Realistically, it's usually the same person the whole way through, so it's okay to go straight from active to queued.
We often see the entire QA or Release phases wrapped up in single mega-stages, but I think that's a symptom of immature practices and we should question it whenever we see it.
There is no distinction in these diagrams between "new" and "abandoned" tickets – it doesn't matter how much work has been done on a ticket, just the nature of any work that remains.
I don't know which transition is equivalent to Jira's "resolve" – it can make sense to set a resolution at "done" and/or at "close".
Edit: 2018-01-30
There are three ways to get work from someone else:
- (internal) assign your job to the other person's queue (or just unassign it and bump it back to the "ready" state.)
- (external) request something (information/confirmation/upstream code changes/etc.) from someone, but retain ownership of the job yourself. This could include creating a sub-task.
In case 2 you need a way to indicate that the task is part of your current workload, but it can't progress until some third party completes some work. To that end, I've added a "waiting" state to each of the three main phases.
Edit: 2020-10-30
There is value in distinguishing the "waiting" states between "waiting for a process that intrinsically takes time/has a known delay/etc." and "waiting for something that requires action to progress". Internally we refer to these as "waiting" and "blocked", respectively. They aren't reflected in the model above, but could be represented by a "needs attention"-type flag on each of the "waiting" states.