One of the challenges I often encounter with JIRA boards is the limited screen real estate available for the ticket summary – often, the visible first few words are not enough to know what the ticket is without clicking on it for detail.
When using sub-tasks, this is often compounded by a sub-task summary which is redundant with the parent ticket, further reducing the effectiveness of the board.
To help improve usability of the board for sub-tasks, I’ve had good success using the “sub-task lexicon” process pattern on a number of projects, described below.
Example Sub-task lexicon prefixes
The following table of example prefixes presumes the following simple workflow states: Backlog -> Selected -> In-Progress -> QA -> Done
A smallish number of prefixes works best to keep it simple and consistent over time – when in DOubt use “DO”:
| Prefix | Description | Typ. Workflow States | Examples | Comment |
| DO | a taskish sub-task | Selected -> In-Progress -> Done |
|
Do a non-code/qa/spec activity
Often requires no AC or QA verify |
| FIX | a bug | Selected -> In-Progress -> QA |
|
|
| IMPL | a story | Selected -> In-Progress -> QA |
|
|
| QA |
|
QA-> Done |
|
|
| SPEC | Description detail, AC | Backlog -> Selected |
|
AC = Accept Criteria
Benefits
- Improved readability on the board
- Standardized prefixes encourage consistency
- Encourages team thinking in a routinized way about typical sub-task workflow “profiles like:
- Feature: SPEC -> IMPL -> QA
- Bug: FIX -> QA
Other notes
- Some teams use sub-tasks for Code Review (CR), others rely on external tools’ code review workflow such as GitHub / GitLab
- Some teams create the typical sub-tasks up-front (typical of scrum’s sprint-planning), others create them JIT (works well with kanban or scrum-ban)
26thcentury 