Looking for those who have advice or experience with large numbers of issues in Jira

[Nancy S. Bennett]

I am working with a company right now that is using Jira for various projects already and looking to move more in Jira but is questioning whether Jira is the best tool for a certain projects that are largely operational and have a high volume of jobs that are very small, only a few minutes in length to maybe a few hours. I know there is no issue limit in Jira, but still I have a several concerns that I would love to know if they are founded or not. I'd love to hear from people in similar situations working with tens of thousands of issues and how Jira has worked out for them. Any advice in any of the following areas would be helpful (or ones I did not think of!).

1.)CSV import: One of the projects involves getting a spreadsheet with maybe 10,000 data tasks. So they have to do an issue import from that file. I know there is no limit to the CSV import but I have  never done that many issues before. Any experience with doing this volume? Any recommendations from experience, like batching or just any gotchas to look out for?

2.)Issue export: One of the projects requires the ability to invoice the customer on the jobs which would require an export of maybe thousands of tasks from Jira. I know issue export has a limit of a 1000 and I aware of the workaround as stated in this KB article. So I realize this is possible but it seems like a hassle, and I wondered if the Jira CLI was something that could help here, not sure. Thoughts?  : https://confluence.atlassian.com/jirakb/increase-issue-limit-for-excel-exports-in-jira-cloud-779160811.html.

3.)Issue Views: Not sure yet what their plan is for looking at the issues for day to day work as well as higher level reporting but I worry about the general ability to see a high volume of issues well in Jira. Jira does not seem great at that. I'd love to hear from anyone that might have seen pain points in this area and what the recommendations are. Things such as performance limits in Kanban boards that maybe individuals would be accessing to pull their work, or in searching large sets of issues. For reporting they will be using PowerBI so they won't be relying 100% on Jira reporting so that helps. Again any pain points would be useful to hear.

4.)Bulk Issue operations: This seems like another area of concern. With a large number of issues comes the need to edit, transition or delete a large set of issues so from what I can tell doing bulk operations gets very slow with a lot of issues. Also what is the limit for this? Again any experience with this would be appreciated.

5.)Archiving strategies: Some projects are ongoing and the issue count will continue to grow indefinitely and these would still be projects that would have a high volume of very short lived issues. I would think that over time there may be a desire to archive or hide away large sets of issues that are no longer needed day to day just for practical reasons or not having so many thousands of issues bogging down your search results. This can be done a number of ways like moving them to separate archive project or exporting them, etc. Just wondering what others might have done and how it worked out for them.

[Hernan Halabi - Elite IT Consulting Group · Accepted solution]

Hello @Nancy S. Bennett I have to say that you have quite unusual requirements. In the past managed a Jira server environment with more than 3000 active projects and 20000 users (can't recall amount of issues but clearly they were many).

I'll provide my input about your concerns as a starting point I would say that Jira cloud doesn't sound like the best solution for this, datacenter would be my option to go if you have enough users, else I would use server. Why? Because you might need to do tweaks that you can't do on cloud. Having this in mind, my answers below

1) 10000 are a lot of issues to import. I would expect slowness on the environment each time this happens, clearly datacenter would handle this better. If the CSV is always the same one after a couple of tests I would try to do it all at once but first I would do partial imports and review that they didn't impact on the configuration of the environment (extra custom fields, resolutions and similar). If possible I would consider creating all the issues via rest rather than CSV. You could decrease the performance impact by slowing down the import.

2) some apps might help you better with this. Eazybi is a powerful reporting tool and might help on this scenario.

3) clearly a kanban board with 10000 won't be an option. It depends on how issues are assigned the options you have to show the users their issues. I can't suggest much without understanding more the scenario

4) limit for bulk operations is 1000 issues. my question here is why would you need to update that many issues if they aren't the same? Why not make more generic issues that cover all those issues into a single ticket?

5) datacenter has issue archiving which sounds like what you need. Else you would have to archive the whole project 

I hope this gives you a better idea and answers your questions. I might have more things to share but would need to understand better the scenario.

[Nancy S. Bennett]

Hernan,

Thanks so much for your response. First the instance is only a 500 user instance and these projects I am talking about are data projects so they are a large volume of very short lived issues (minutes in some cases) as this is an operational team and that is where the large issue count comes into play. Also I am not sure what the requirements are because they have not taken the plunge yet but I agree with you comments about having at least Jira server because the ability to configure is much greater and also the options for greater capabilities with plugins is better too.

1.)Good comments on that. I was thinking Jira CLI but REST is a good idea too.

2.)Great response, I will check into that.

3.)I am all too aware of the performance degradation in general with issue count and Kanban boards (Scrum boards too) but don't know exactly what the practical limit is. I know in no way would it be practical anyway to view thousands of issues in a  Kanban board even if it did perform (which it definitely won't). The card layout is very visually inefficient anyway even for less than 100 issues. I think they will have to figure out what their "micro views" look like and if operators process issues every 5-10 minutes, each person may process say 50 issues a day for example (and I don't know yet how many people, this is a new client).  They are really working in a queue but it is not a Service Desk scenario because there is no back and forth. So I am trying to figure out how might they view the top of their queue in the Kanban board effectively, and what the limits would be if we did that, would it be 100? 75?  Don't really have an answer here just trying to clarify the scenario better.

4.)The tickets are all unique as they all represent different jobs. The bulk edit scenario I just assume might come up. I just tried to think if it were me and I had all of those tickets and I had to bulk edit them for any reason, could I do that? Things like adding a label to a group of the issues, or changing a field value to a subset of them. Not even talking all of the tickets but what about even some. With the large volume it is possible this will come up.

5.)Good feedback on suggesting data center. I will take a look.

My client is unsure they will go in this direction, based on my reservations, so I am just trying to collect the information to give them to help them make the best decision. I don't want to over estimate or under estimate any of the problems they may run into. Thanks again for you feedback!

Nancy

[Hernan Halabi - Elite IT Consulting Group]

hi @Nancy S. Bennett glad to know that the feedback helped.

About item 3 maybe that just need saved filters rather than an agile board. Might be easier to use the transitions rather than drag and drop with so many issues around.

If client isn't certain you can always deploy Jira with a trial license and see for yourself how it looks/behaves under this scenario.

[Nancy S. Bennett]

I was thinking the same thing. Thanks for your input.