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

[SkyIsFalling]

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?

[BenP · Accepted solution]

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).

Setup

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)

Problem/Solution

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..

Cheers,

Ben

[SkyIsFalling]

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)

[Mehmet Kazgan]

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