Jira Agile - planning board is really slow. Could it be the filter we use?

We have a scrum planning board that takes a very long time to load. There are a few "quick filters" we defined, and when we try to use those, it takes even longer before the page is loaded.

We're still new to Jira Agile (having done scrum before only in the physical world, with pieces of paper on a whiteboard) so I'm wondering if we're trying to use Jira Agile the wrong way.

The planning board is based on a filter that basically encompasses all of our 70-plus projects (with some exceptions), includes certain people only (members of the dev and QA team), and tests for certain conditions with versions.

This filter ends up with over 1000 results.

The quick filters are used to bring out individual users. When we use these, that board is so slow its pretty much unuseable.

Other parts of Jira, while not blazingly fast, do not exhibit this level of slowness.

I tried to create a "Test" board that only encompassed one project, and that board is fairly quick.

So the question is, how do I optimise the filter so that the scrum planning board loads in a reasonable amount of time? Any tips/tricks/insight on how to make it run faster?

Or, to put it another way: is a filter that pretty much encompasses most of our projects just a bad idea?

3 answers

1 accepted

0 votes
Accepted answer

We had a board initially with swimlanes based on queries; columns mapped to statuses & quick filters based on people. While the view is handy, the board performance on "Work" mode is terrible.

Other than a slow initial load, we saw reassigning/editing an issue in the board would cause the board to refresh for a long time (30s seconds being no exception).


1. Swimlanes

* External bugs:

issuetype = Bug and Customer is not EMPTY

* Story work:

issuetype = Story or issue in parent("issuetype = Story")

* Epic test work

2. Columns: Open + Reopened / In Progress / Resolved (in test) / Closed

3. Sample quick filter on USER

assignee = <USER> or (assignee was <USER> during(startOfDay("-1"), endOfDay()) and status != Open)


The problem is that the base query for your board determines all the data that is sent to front-end.. the remaining filtering of swimlane definition & filter buttons is (apparently) done in the browser. I assume the scrum board quick filter implementation's performance will be improved.

  • Check the query performane on the JIRA server (slow queries / regular log)
  • Try to limit the base query recordset & exclude data that will never get shown/used (due to combination with filter buttons/JQL on swimlanes).
  • We eventually solved our problem by creating a new scrum board which is based on the same base query, but defined the users as Swimlane & redefined our Issue Type Grouping (previous swimlanes) into Quick Filters on top.

Today, we are still using the original (slow) scrum board, but only on "Plan" mode, while the new (speedy) board is used for our daily scrums / "Work" mode

I hope this workaround works for you as well..



I would first reindex and see if it makes any difference. Then you might want to increase memory for JIRA

Thanks guys, for the input/suggestions.

I am going to try and see if the workaround might work for us.

For now, we re-wrote the filter to not include just-about-everything, and things have definitely improved (though sadly still slow)

Suggest an answer

Log in or Sign up to answer
Community showcase
Asked Dec 06, 2018 in Jira Ops

I'm John Allspaw, Ask Me Anything about incident analysis and postmortems

I'm John Allspaw, co-founder of   Adaptive Capacity Labs, where we help teams use their incidents to learn and improve. We bring research-driven methods and approaches to drive effective inciden...

5,597 views 22 17
View question

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you