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||
|SPEC||Description detail, AC||Backlog -> Selected||
AC = Accept Criteria
- 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
- 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)