Implementing Blocker tracking in Jira Cloud

This is the third article of the blocker series. In this post, I’d like to share a step-by-step Atlassian Jira configuration for the Cloud product to track the blockers at an organisational level and be able to report on them.

In the first article we talk about the nature of blockers, in the second is how we can understand the root causes of blockers and in the third, we will talk about how we can implement lightweight automation to gather the information across all your teams in a structured approach.

How a team request created a new way to track impediments

A few years ago a team invited me to facilitate a blocker clustering session. This team was doing this exercise every couple of months or if they detected they were being blocked a lot. This team was capturing all their blocker in a spreadsheet, there was quite a discipline to fill all the data and sometimes this was not enough as when we tried to dig into specific blockers half of the time they did not remember what triggered the impediment and the other half as the data inaccurate as was filled days after the blocker happened. So I came to my desk determined to find a good solution.

These were my design principles:

1. The process should be lightweight so that process is not impacted.
2. It should have some level of standardisation so we can perform analysis in teams, areas and at a company level.
3. It should be generated in real-time.
4. It should capture the context of the blocker.

The implementation was simple, every time a ticket went into the status “Blocked” the team member should fill in the blocker information and the subtask is created capturing all the important data.

How to implement it

The general overview of the implementation is to create automations to create a sub-task of type blocker when a ticket is transitioned to a blocked status, and when the ticket transitions again to an unblocked status the blocker is automatically closed. This Idea can be implemented in many different implementations, let me share mine if you can use it as inspiration.

In this video, you can see the complete automation.

Requirements:

Blocker Automation

• JSU Automation Suite for Jira Workflows
• Blocker Reporting

Jira to Google Sheets integration

• Google Sheet
• Looker studio

1. Define the standard reasons a ticket could be blocked

Is critical that every time a ticket gets blocked you can apply a category, this will allow you to perform analysis. Every company has its own ecosystem with its own ways of working and main reasons a ticket could be blocked. When you are going to start defining have in mind the following principles:

• The reason should be brief and easy to understand.
• You should avoid having too many
• The reasons should be mutually exclusive
• They should remain stable for a period of time

Regarding the last point, it is important that you maintain the same blocker categories in time for reporting purposes and at the same time if you want to track something specific you add it to your reasons list and communicate to all the teams.

This is an example list:

Access Restrictions: Problem accessing repositories, databases and other restrictions of components.

Critical Issue: Issues in the production environment that require us to stop what we are doing and focus on the issue immediately.

Dependencies on other teams: Dependent developments, services, components and capabilities developed by teams belonging to the company.

External Dependency: Dependent developments, APIs, components and capabilities developed by external companies.

Infrastructure: Networking configuration or issues that prevent us from continuing the development.

Internal dependencies: Dependencies within the team, expertise, knowledge or handover work.

Priority Change: Changes in the priorities and focus.

Security and Compliance: Security and compliance approval, design definition.

2. Create custom fields

To create the custom fields you can follow this guide: Create a custom field

You should create the following custom fields:

Name

Field type

Blocker summary

Text Field (single line)

Blocked reason

Select List (single choice)

Blocked on workflow transition

Text Field (single line)

3. Create a Blocker screen

To add a new screen follow this guide: Configure issue screens

The blocker screen should contain the following fields:

• Blocker summary
• Blocked reason

4. Add Issue Type Sub-task “Blocker”

Create an issue type called Blocker, it’s important to configure it as a subtask. To learn more about how to perform this you can read Add, edit, and delete an issue type

5. Create a Blocker simple workflow for the Blocker.

Now is time to create the Blocker workflow that consists of 3 states, Open, and Discarded.

Note: Is important to create post functions to mark the tickets as automatically as resolved. I used the “Update Issue Field Function” as configured like the image below.

6. Associate the Issue Type and the workflows to the project

In this step, you are going to Add the Blocker issue type of your project to the Issue type scheme. Associate issue types with projects

After that add the workflow to your project and configure it for the blocker issue type

7. Edit your workflows to add a blocked status

Looking at the workflow below you can see that I’ve added “Blocked in Development” and “Blocked in QA”, we will call these transitions “Blocked states”. When you add a transition back to the “Active state” (from “Blocked in Development” to “In Development”) you don’t reuse the transition that connects, in this example “Selected for Development” to “In Development” as we are going to add post-functions to it.

8. Adding the transition configuration from “Active state” to “Blocked state”

a. Add the screen “Blocker” we just created in step 2.

b. Click on post-function.

c. When the post function screen is open click on “Add post function” (you should have installed the JSU Automation App)

d. Select “Create A Linked Issue (JSU)” and then click on “Add”

e. In the Configuration screen we are going to select:

1. Precondition: False
2. Copy or Move Attachments added during Transition — controlled by Custom Field: *** never copy attachments ***
3. Copy Existing Attachments — controlled by Custom Field: *** never copy attachments ***
4. Target Project: Inside the same project
5. The new issue will be related via Sub-Task (the issue type of the new issue must be a Sub-Task)
6. Issue Type: Selected issue type (Select “Blocker”)
7. Perform as User: JSU Add-On User
8. Issue Assignee: origin issue’s assignee

9. Sub-Functions: Create a Linked Issue

Configure the bottom part of the page with the following configuration:

10. Click Update

Move it down using the arrows on the right to below “Update change history for an issue and store the issue in the database.”

g. Add another post function, this time select “Update Issue Custom Field“

h. Follow this configuration:

1. Issue Custom Field: Flagged

2. Custom Field Value: Impediment

9. Adding the transitions configuration from “Blocked state” to “Active State”

Now the next step is to configure the workflow post-function coming from the blocked status to the active one (“Blocked in development” -> “In development”) to automatically close the blocker, clear the custom fields and remove the flag. We are going to add the

Close automatically the blocker subtask:

10. Apply and publish the workflow

These are all the steps you need to follow to track the blockers. Apply these changes to all the workflows and transitions in all your teams.

11. Example of o Looker studio report

Using the Jira plugin Jira Cloud for Google Sheets (Official) and configure it the query all the blockers that are not discarded:

1. Import type: JQL
2. JQL Query: Type = Blocker and status != Discarded

You can select the fields you want, it’s important to include:

1. Key
2. Summary
3. Project
4. Created
5. Status transition date
6. Blocked reason
7. Blocked on workflow transition

Having the spreadsheet updated daily I’ve created this data studio report you can be inspired by:

Conclusion

With this configuration, you will be able to understand where you should focus to provide meaningful changes to help your team move forward.

In the next article, we are going to configure Jira to provide the cost of each blocker taking into account different variables and ways to do it.