Many of my clients and the people I talk to are using Jira – it seems to be the default choice here in Australia and no doubt in some other countries for Agile teams. However, I have personally found the Kanban implementation lacking many things and over the years have had to implement a number of “Hacks” or workarounds to get it to work somewhat closer to the Kanban that I understand. Ideally, if you want to go deeper with Kanban you should be looking at tools like Kanbanize, SwiftKanban, or LeanKit but in true Kanban spirit, we’re going to “Start with what you do now” and look at how you can get more out of Jira. In the detail below, I’m also looking at a new Jira plugin called EasyKAD which has some useful features.
The “No sub-columns” problem
The Problem
This problem is fairly straightforward, basically, Jira doesn’t allow you to have sub-columns. Here’s an example of part of a board in Kanbanize that has subcolumns:
What is useful about this is that you can very clearly see what items are being worked on and which items are ready for the next step in the process. You might say that “Jira can do that, it’s just two separate columns”, which is true. However, the key to this is that the WiP limit is above both columns. This prevents people from starting new items if the next part of the process hasn’t picked it up – in this example, developers can move downstream and help testers fix bugs, write automation or anything else to get the flow moving again. Usually what happens in Jira implementations is that you put a WiP limit of 5 above each (creating higher overall WiP), or perhaps you do 3 & 2. Either way, what happens is at some point the “Done” column fills up and there’s something else that gets finished from “In Progress”. Where does this go – essentially either you break the WiP limit in “Done” or you have a “Done” item sitting in “In Progress”. Now your Kanban system doesn’t reflect reality, nor is there enough stress on the system to enable change or the increased WiP is throwing out lead times & predictability. Additionally, your data is going to be out – it looks like items are “In Progress” rather than queued up, further putting less stress on the system to fix the queuing and WiP problems.
Possible Solution(s)
The way you can get around this is to add both statuses to a single column – here is the view in Jira for the board settings
However, this leaves you with a view on the board where you still can’t really distinguish between what’s in progress and what’s done:
You can do something like the following below to add the status to the cards on the board so that you can distinguish them:
Here’s a view on the board:
Alternatively, you could change the card colours based on the statuses to give you a better visual:
Jira EasyKAD Plugin
This is probably the easiest and best solution to the problem that currently available. Here’s an example:
As you can see, you can create sub-columns here with WiP limits on the parent column and the sub-columns. It should be noted that there is currently only one level of sub-columns allowed, so you can’t do multiple nesting. However, based on the example above, you can actually apply WiP limits properly and create a real pull system which is a vast improvement on the Jira default and better than the other “hacks”.
The “Single Workflow” Problem
The Problem
Again, the problem is fairly simple – essentially you can’t have different workflows on the same board. Here is an example (straight from one of the template Marketing boards) from SwiftKanban:
What we want to show is different work item types with different workflows that are done by the same team or are related services. We want to see all of the work together, reflecting the actual process. You can see in the above, general marketing tasks have a different workflow compared to running events. There’s also different WiP limits involved and we want to control those independently – however I’ll deal with WiP limits more broadly below.
The Solution(s)
One way people have tried to solve this is to come up with “common” workflows for both and put them on the one board. I don’t really think this is a solution – it’s more of putting a square peg in a round hole. The problem with this approach is that neither workflow is a true reflection of what is going on and you run into problems understanding what’s going on in the flow as well as making improvements. I would not recommend doing this.
The only really viable solution to this is to have two separate boards – one with each workflow. It’s not ideal, because you can’t see all of the work together, but at least you can see each workflow and get accurate data so that you can track it and make improvements on the system of work. You may need the assistance from a Jira admin to help with status management at this point as well. Essentially, if you have a Jira project and the Simplified Workflow, all statuses for all types will appear in the drop down. What commonly occurs is that people, whilst in the issue view, update the status to something outside of the workflow for that type. You will need your Jira admin to create a specific workflow for that type for your Jira project so that you don’t get them mixed up and have missing cards.
The “WiP Limit” Problems
The Problem(s)
There are several problems here:
- Can’t assign WiP Limit to a swimlane – This can allow you to control the flow based on things like work item type or class of service. See below where “All Marketing tasks” has a WiP limit of 50, whereas “Events” has a WiP limit of 5.
- Can’t assign WiP Limit to different sub-columns – although above we talk about putting a WiP limit above a column, sometimes you want the sub-parts to have WiP limits as well (see below under Events -> Execute)
One thing that is positive about the way Jira has implemented WiP limits is that they’ve included minimum WiP limits. This is useful for upstream to make sure you have enough demand for the capacity, but also if you want to implement CONWIP style limits (ie the minimum and maximum would be the same).
The Solutions(s)
Can’t assign WiP Limit to a swimlane
There is no way in the tool to achieve this. The only way to do it is to establish a policy for the board and make sure when you perform replenishment that you do a count of the items to make sure you haven’t gone over the WiP limit for that lane. This becomes more difficult to manage for “on demand” replenishment as there may be other policies in place to allow the team to “pull” work into the system.
Can’t assign WiP Limit to different sub-columns
Here’s one way that you might want to deal with this – in this case I’ve added a WiP limit of 2 to the “Development – In Progress” sub-column / status using a Quick Filter:
Note that the limit is included in the filter so you can do a quick check / count of what’s on the board. I’m not aware of any other ways with a basic Jira install to make this more visible / obvious that the WiP limit has been breached on the board – it also requires you to actively click the filter to check for problems.
However, if you install the Jira EasyKAD plugin, you can put WiP limits on sub-columns.
The “No Policies on Board” Problem
The Problem
The policies around how the board works is not able to be attached to the board in Jira. That is, things like “Definition of Ready” / “Definition of Done” can’t be placed onto the board.
Here’s an example in the Kanbanize tool:
What’s important here is that the definitions are present in their context (just hover over the column name to see it). Team members can see this right away and understand collectively “how the work works”. It’s useful for new starters and auditing as well because you’ve effectively made the system policies explicit in the workflow. It also means that when there is an issue, the team can collectively review the policies and make improvements to the system of work immediately.
Jira doesn’t allow you to do this and it often leads to confusion as to how the workflow works.
The Solution(s)
In the days pre-COVID, with a number of the teams I worked with, I actually replicated the boards in Jira with a physical board. You could put all the policies you like on the physical board and ensure understanding and improvements take place. However, since COVID this is not an option for most and we’re more reliant on the tools than ever. The other downside for this is that you’re now maintaining duplicate information and usually one will be out of sync with the other in some way.
Another possibility is to record the policies somewhere else. Teams with Jira often also buy Confluence, so this might be a natural place to store this policy information. However, this is less than ideal as it’s detached from the context of the board and in an “information refrigerator”. Oftentimes this is ignored, unknown and is just not used. It’s not ideal, but it’s really the best option I can think of without a physical board.
Another way to achieve displaying policies is to create an issue type of “Policy”, then create a few policy cards for steps on the workflow. Move the cards into their respective statuses. Create a swimlane on the board above the others for “Policies”. Here’s an example:
The “Single Assignee” Problem
The Problem
Jira, by default, doesn’t allow for more than one assignee per card. Using the Kanban practices, we often see improvements in collaboration and teamwork and often get to the point where multiple people could be working on a card. We should see that reflected on the board so that we can see the work everyone is working on.
The Solution(s)
One way to do this is to add an additional field. Now, you can either add a single field with the user picker, or add a Text Field and include people referenced by the name (using the @ character). Generally, the user picker is better because it has greater query ability and visibility on the cards, but it is restricted to one user. If you commonly have 3 people collaborating, you may want to add 2 additional fields.
You will need to be a Jira admin to add the new field and apply it to the necessary screens:
Once it’s available to projects, the users can see it in their issue view and assign it.
You will need to edit your board layout if you want to see this extra field on the cards:
You can now see collaborators on the board:
Jira EasyKAD Plugin
It should be noted that this plugin has solved this problem. It adds two new fields “Whatties” and “Howies” that are for people who define “what” the work / need is and for those doing the work respectively. You can add multiple people to each of these fields and they appear on the board:
and the card on the board:
The “Poor Data” Problem
The Problem
There are a couple of key problems here:
- There’s not many data reporting options – really on Cumulative Flow and Control Chart (the CFD is actually not too bad)
- The Control chart is not particularly good
I’ve never been a fan of Jira’s control chart. I find just looking at it can be really jarring and I find it hard to get useful / actionable information from it. For example, here’s an image from Jira:
Note the Y axis – the scale is changing as you go higher up the chart. I don’t know about you, but when I was taught basic graphing skills in high school, this was always supposed to be a consistent scale. This assumes the interesting things will be at the bottom because it has the most real estate on the chart. In reality, it’s probably the items at the top that you need to focus on. This actually distorts your view on the data and limits, or even taints, what you can get from this kind of report.
The other is that it’s using standard deviation to improve “predictability of cycle time”. This assumes that predictability is the goal (“fit for purpose”). You may want to focus on raw speed rather than predictability, or perhaps something else such as profit / costs. This won’t necessarily help you with that. My opinion is that this is a manufacturing take on using data, rather than one that is specific for knowledge work where the Jira tool is aimed. I’d prefer to see other metrics such as percentiles so that I can make a decision on what to do based on the purpose of the team / service.
The Solution(s)
My first suggestion to anyone who’s using Jira and can’t move to another more suitable Kanban platform is to install the Nave plugin for Jira. This has fantastic metrics and will allow you to make a myriad of improvements using the data.
It has histograms and scatterplots for Cycle Time and Throughput, plus it has a great “Aging chart” where you can see problems in the system right now. One thing I find really useful is that if you use the “Flag” feature in Jira for blocking items, you can get additional data for this.
I know there are some people out there that can’t add plugins for various reasons into Jira. If you’re one of those people, then here’s another potential option for you (although it’s a bit manual). For each status, add a field with “Date Time Picker” type.
Create an automation to update that date every time a card moves into that status on the board:
Then, when someone moves the card, it will update the date:
You can query the data and pull out the dates you require using the CSV export on the “Filter results” screen. Then, you can use something like Troy Magennis’ Cycle Time Calculator spreadsheet to copy the key dates into which will produce charts for you. You can find the charts on his Github page.
The only other option is to call the Jira APIs and extract the data yourself and create the visualisations – but if you’re doing that, you may as well buy the Nave plugin.
Conclusion
That’s all for now folks – there are other gaps, but I haven’t covered everything here. If there’s anything important that you think should be covered, please let me know.
Jira has a very basic Kanban implementation – it may be useful to get you started, but it will continue to hold back the maturity of your organisation unless you do some of the “outside of the box” solutions above. For anyone using Jira for Kanban, I would recommend using Nave for the metrics. I’d also recommend you check out the Jira EasyKAD plugin if you want to make your board appear more functional. Note, that at this time because of the way they work, it’s not possible to get all of the data from EasyKAD into Nave. If you can, you might want to try one of the other tools such as Kanbaniz, SwiftKanban or LeanKit which have Kanban front of mind when they designed the tool for those looking for greater organisation maturity without the workarounds.