@Dan Breyen has already pointed to the bugs I would have mentioned, so I'm not going to repeat that bit.
But you might try simplifying your board.
Jira has to run many filters, many times, on a board, and each one imposes compounding work effort on the system. The more issues a filter returns, the more work it has to do.
A board is always based on a filter. The defaults, and the boards that use fixed filters you can't change are usually "Project = XYZ and issue is not 'done' for how this type of project defines it".
But boards then can run three more sets, possibly four!
- I believe the "current content of a column" is not done as a JQL filter, but I'm not sure (that's the "possibly four")
- Issue colours
- Quick filters (these need to be run when loading or refreshing the board, not just when clicking on them)
- Swimlanes
A board with 2 colours, 3 quick filters, and 4 swimlanes can be running 25 filters on any given operation, and all of those are slower the more issues they return.
If you can't simplify your filters for colour/swimlane/quick, then you should look to the volume. Try to reduce the number of issues. Do you really need 70 issues in a column? Probably not. 70 issues is getting towards the higher end of the number of issues you should have on a team's scrum or Kanban board entirely. (A scrum board would only show the current sprint, a Kanban - maybe yes 70 in "done", but you should probably be releasing well before you have 70).
Atlassian say boards really become unusable at 500 issues. I say you really start to suffer when going over 300 technically, but the humans probably start getting confused and lost before you hit 100 - it's just too much for a team to try to deal with in a sprint.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.