Agile Board is Unuseably Slow

[Nicole Williams]

I just took over an Agile board, and it is so slow I can't use it. If I even click on anything my browser hangs for 30 seconds.

The Board

When I click on the board and go to the associated filter, it literally shows every ticket in our system.

Our columns are mapped to 8 statuses.

We use filters as swimlanes (approximately 30)

We have quickfilters by assignee(20) plus 2 quickfilters for updated recently.

Obviously it's pulling WAY to much data, but I was wondering if there are best practices for optimizing the query. I can't limit it to one project because the versions span multiple projects. I could limit it by assignee, but there are 20 people. Is there a maximimum number of quickfilters or filters I should be limiting myself to?

Please help.

[Nic Brough -Adaptavist-]

The quickfilters only really kick in when you use them. I find the main things that load a board are the baseline query and (to a lesser extent) the swimlanes, as they're all directly involved in the rendering up-front.

30 seconds a click is by FAR too slow. To investigate, could you try a quick test - create a new board with the same filter, but no swimlanes or quick-filters. Don't put any sprints or new epics on it either. Now, how does that handle? Does it seem ok?

Secondly, how many issues does the baseline board filter pull back? Cross-project shouldn't matter too much, but if the filter is pulling in 1000's of issues, then that could be a significant part of the problem.

[Matthew Gately]

While this may not help the original poster, I want to comment on one of your statements that may help others who arrive at this page (it helped me!).

You say "Cross-project shouldn't matter too much."   In my case, the cross-project aspect of my filter query is the only thing that mattered.

I had a filter query that returned on 64 results, so very minimal.  However, the filter query didn't have any explicit statements like "project in (a,b)".  The Agile board then assumed that the filter query involved all 278 projects from my company, while it really only included items from 5.  With this query, it took like 30 seconds to load the page, and again after any editing of a ticket.  Also, dragging items was pretty much impossible.

When I looked at the filter configuration, it listed the board as having 278 projects, which tipped me off to the problem.  Once I updated the query to make sure that the Agile board parser could easily tell the number of projects the filter would return, it fixed everything up.

Again, let me stress, my filter results were identical to before (64 tickets), however, the Agile board processor must have quite a bit of logic involved in checking all projects it thinks could be returned by the filter.  Simply updating the filter, but in a way that still returned the same results, fixed my latency issue.

[Nic Brough -Adaptavist-]

mmm, 4 year old post...  Things have changed.

[Jack Brickey]

hey it's a slow thread! ;-)

[Daniel Wester]

What browser are you using? Older IE versions can be slow...