Nicholas Muldoon

Agile team? Want to get the most out of JIRA? Check out JIRA for Agile Teams.

UPDATE: I’ve revised my approach and added new details. Read this post first then continue with part 2.

I had been looking for a way to visualise epics across a number of teams and programs in JIRA and GreenHopper. I want to highlight those epics which are blocked. What I have settled on is a combination of JIRA, GreenHopper and an add-on for JIRA called JQL Tricks.

First off, picture a company with X strategic goals for the year. These goals are shared across the company and engineering departments use them to set their quarterly goals. Break down the departments and each team sets their goals, again that align with the company goals. These team level quarterly goals are represented by Epics in GreenHopper. The higher level goals are listed on a Confluence page.

Further, the achievement of some teams goals depends on other teams. And the company wants to map the strategic goals down to the tactical work that each team is up to. Of course, each team should be working on the highest value goal at the start of the quarter, so that if the team is to miss achieving any goal it is the least important.

Providing visibility for the management team is a great way to minimise disruptions to engineering teams – all the information is there in JIRA, let’s just bubble it up to something that is sensible for the management team. So, we don’t want to provide visibility for the stories in a sprint, instead we want to visualise a roll up of epics (team goals).

Visualising Epics

Start by creating a Kanban board in GreenHopper with a simple three column mapping – To Do, In Progress, Done. Change the filter on which the board is based to use the following query:

“Epic Status” = Done or “Epic Status” is not Empty ORDER BY Rank ASC

The filter configuration then looks like this:

Note: The Work Sub-Filter takes those epics/goals completed in the last quarter off the Work mode of the board while still making them available on the Report mode (more on this below).

Once you have the board and filter set up you’ll see this:

Epics. To Do. In Progress. Done. Easy.

Dependency Management

Next up, we need to visualise the dependencies. I want to highlight those epics that are blocked – again, we’re focusing on the highest value goals at the start of the quarter, so if anything falls off the list it is the lowest value. Trouble is, if we’re dependent upon another team and they are not aware of it (or not working on the corresponding goal early enough in the quarter) we may miss two high level goals. This is where the JQL Tricks add-on saves the day.

JQL Tricks provides some fancy JQL queries which help us find the dependencies. I started out with:

project in (“XYZ”, “ABC”) AND issue in linkedIssuesHasStatus(“Open”,”is blocked by”)

This JQL query searches for all issues in the project XYZ and ABC that have a linked issue that is Open and where the link is of the type ‘is blocked by’. It turns out that JIRA runs two queries on the search index for this query – before and after the ‘AND’ – and then finds the ones that match both halves. This is an expensive search query on large JIRA instances.

Thankfully, the team at J Tricks (kudos fellas, thanks for the help!) sorted me out by suggesting the following:

issue in linkedIssuesInQuery(“status = Open and project in (XYZ, ABC)”, “is blocked by”)

This means that it does the search for issues linked by ‘is blocked by’ on ONLY those issues that match the first query – ‘status = Open and project in (XYZ, ABC)’. This is much faster and gave me the same results. Gold!

Next step, add this to a board. I chose a swimlane for this:

And voila, we can visualise epics across the company and highlight the blockers. You can even turn this into a nifty JIRA Wallboard and put on a TV next to the management team.

Cycle Time

Cycle time is the amount of time that an issue spends in progress – in this case the amount of time that an epic takes to be completed from when we start working on it. You can use the Control Chart to visualise this, unfortunately I don’t have enough data around this yet. Stay tuned for an update in a quarters time.

Next Steps

I’m still trying to figure out if I need an In Progress column. Perhaps Epics are only in two states: To Do, and then Done. If you have any thoughts please share them in the comments below. Of course, to get the cycle time I may need to keep this and do something with the workflow in JIRA to push the Epic into In Progress when we start working on the first issue linked to that Epic… more on this in the future.

Finally next thing is highlighting the Epic Reports (another great feature that GreenHopper gives product owners, and which can help the management team). Here is an example from one of those epics on the board above:

Note: today you can only get to this report via the associated Scrum board as there is no Epic Report on the Kanban board. The GreenHopper Team has a story on their backlog that will make this easier – vote on that.

So, that’s one way of visualising epics and dependencies with JIRA and GreenHopper.

UPDATE: I’ve revised my approach and added new details, continue with part 2.