Can I improve Kanban performance?

Aron Kuch_fggy62

One of my Jira Cloud, company managed software projects has ~2700 issues on it, although filtering only shows the ~300 active issues. The Kanban board has 25 columns/statuses (four-times more than I would choose, but it's not my choice). Moving an issue from one column to another has become unbearably laggy, if it's not to the immediately neighboring column. This has only become a problem in the last month or two. Any ideas what the problem might be and how to fix it?

Nic Brough -Adaptavist-

Hi Aron,

There's a lot of stuff to try to look at here, but it can all be described as "complexity".

(With the exception of "network or client speed" - if you've got a slow connection or a desktop/laptop that is slow, there's not a lot you can do there)

You have already mentioned two of the main complexities, but there are a few more that are less obvious.

• Project size is not a huge problem, Jira's index is optimised for project and a handful of other system fields, so "project X has 2,700 issues, or 270,000 issues" is nothing to worry about.
• The next one is what the board selects for.  You say ~300.  That's the maximum I would recommend, although
• I want to say "active" issues - ones that are not "done".  It's Ok to have 300 in the board and backlog, even when you've completed 30,000 - again, Jira is optimised for ignoring "done" issues on a board (other than the ones in the current sprint or version)
• Atlassian recommend an upper limit of 500, last time I asked.  I may be out of date, but I try to stick to saying "try to keep it below 250, although the odd 300 won't hurt much"
• A minor issue with performance can be the content of fields an issue displays on its card.  The main trick there is "do not use long text fields that might have 'clever' formatting".  Just getting that one out of the way before I move to what your main problems are likely to be.
• You mention moving issues between columns is slow.  This is usually down to
  • You have post-functions, automations, or validators that are slow in your workflow.  This is an individual issue problem, not a board problem, but worth checking (if you find you have similar boards with very different "move to new column" performances)
  • The next bit!

You have also identified the columns as a problem.  This is where we go into the main thing that tends to slow boards.  Boards rely on filters.  To get a board, you have to compound them.

This is slightly easier to explain with a worked example.  Let us say you have a board with lots of issues, and a load of clever configuration.

• Jira runs the board filter (project = XYZ)
• Which are divided into columns, by a status filter
• Which are divided into colours, by a priority filter
• Which are divided into swimlanes, by a swimlane filter
• Which are divided into quickfilters, by a custom filter (which, yes, it does have to run to each time to identify what to offer)

If you have a project and board with 300 active issues, 25 columns, 10 swimlanes, 4 colours, and a quickfilter for the 6 possible issuetypes, then Jira could be trying to run up to 6,000 filters every time you try to do anything on the board, across those 300 issues.   That is never going to be quick.

TLDR: you need to simplify your board (workflow, volume of issues, colours, swimlanes, and maybe quickfilters if they are complex, but certainly go back to your teams to tell them "25 columns is a big problem"