Process Pattern: Blocks and Blocked Swimlanes

Identifying and mitigating blockers is one of the most important practices in keeping projects on-schedule and maximizing throughput.

I’ve observed three different practices used for JIRA projects in the past to track blocked work:

  1. Flag – this provides a strong visual indication on the board, but requires the flag be manually added / removed
  2. Blocked workflow state – clear board visibility (mapped to column), but requires the state be manually entered / exited
  3. Priority field set to Blocker – clear board visibility (same as for any priority field value, may optionally be swimlane’d), but requires field be manually set to Blocker / back to other priority

The approach I like to use is to rely on the JIRA Blocks / Is-blocked-by link type, to show both blocked and blocking tickets, each in their own swimlane at the top of the board. “Blocking” tickets are important to track when your project is blocking another.

These filters require the popular Adaptavist ScriptRunner plugin be installed on the JIRA server.

Example JQL Filters for Blocked and Blocks

JQL Filters

The intent of the generic JQL filters described here is to support adding “Blocks” and “Blocking” swimlanes to any JIRA project’s board.

AllProj-BlockedDirect: Returns all open tickets having a direct “is blocked by” link to at least one open ticket

issueFunction in linkedIssuesOf(“status not in (Done, Rejected)”, blocks) AND status not in (Done, Rejected)

AllProj-BlockedAny: Returns all open tickets having a direct or indirect (parent of blocked sub-task or sub-task of blocked-parent) “is blocked by” link to at least one open ticket

(filter = AllProj-BlockedDirect OR issueFunction in parentsOf(“filter=AllProj-BlockedDirect”) OR issueFunction in subTasksOf(“filter=AllProj-BlockedDirect”)) AND status not in (Done, Rejected)

AllProj-BlocksDirect: Returns all open tickets having a direct “blocks” link to at least one open ticket

issueFunction in linkedIssuesOf(“status not in (Done, Rejected)”, “is blocked by”) AND status not in (Done, Rejected)

Add Blocked and Blocks Swimlanes to board

The following JIRA board swimlanes are defined as:

  • Blocks: Show all open project tickets directly blocking open ticket(s) on any other project
  • Blocked: Show all open project tickets directly or indirectly (parent-of or sub-task-of) blocked by open ticket(s) on any other open project

screen-shot-2017-02-20-at-4-32-24-pm

Notes

  • To run any of the above JIRA filters standalone for a project (outside the board), simply add a “project=” clause and save them to a project-specific filter name
  • Using Resolution instead of Status can potentially simplify the filters, depending on how JIRA is configured in your organization. In either case, include all status / resolution states which are considered “non-open”
  • Be sure to set the saved JQL Filters permissions to “Everyone” or another permission level giving everyone access who needs it

 

 

 

 

Process Pattern: Sub-task lexicon

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 Test Env. config.
Do a non-code/qa/spec activity

Often requires no AC or QA verify

FIX  a bug  Selected -> In-Progress -> QA
  • FIX Error when saving
  • Code the fix
  • Unit-test the fix
IMPL  a story Selected -> In-Progress -> QA
  • IMPL User REST resource
  • Code the story
  • Unit-test the story
QA
  • E Test
  • Verify
QA-> Done
  • QA Error when saving
  • QA User REST resource
  • “E Test” = Exploratory Test
  • Verify ensures AC are met
SPEC Description detail, AC Backlog -> Selected
  • SPEC  User REST resource

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)