You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Question to the lovely hive-mind...
Assume for argument's sake I have, say, 10,000 live Issues on one single very old Project, and only, say, 5 Kanban Boards (2,000 Issues per Board!) – and so obviously I am noticing massive slowdown and performance issues... ok, so...
Assume I now split the Project into say, 20 Boards (one per "mini project", filtered by Epic/Components etc), so it's max 500 per Kanban Board – not ideal, but live-with-able...
My question is: does this actually improve performance for each Board? Is the slowness/bottleneck caused by the number of Issues in the Project (filter) as a whole, or only on each Board (filter)?
Will I see net performance gain by breaking up one Project into many Boards like this?
Yes. Spit your boards up.
On a technical level, Jira is built to work with a useful and sensible workload. Atlassian recommend having fewer than 500 issues on a board for the performance, but as a consultant, I'd say your team is probably failing if you've got more than 100. (Note that's not the backlog, it's just the active issues, and sub-tasks don't count)
A project with 10,000 open issues is screaming that it has failed because you have not been dealing with them.
There are two big factors in board performance
1. Number of issues
2. The amount of filters it uses. The core board filter is not a problem, but if you use quick filters, board colours, or swimlanes, your board is running many filters. Even something that looks simple with one board filter, two swimlanes, three colours and four quick filters is running 25 filters every time someone views it. And then you have to multiply that by the number of issues each one returns...
Yes, they will, but not a huge one, because the board filter effectively ignores backlog and done (for Kanban, done means it won't be in the last column of the board, usually "we've set a version on it"., for Scrum, it only selects for the sprint, and for most other boards, it's more "not touched for two weeks"). The board filter is usually looking for positives rather than negatives, much the way humans can look at a spreadsheet and identify lines where certain data is there, rather than empty or an uninteresting value.