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
We have a SAFe programme running which has been set up using individual projects per scrum team, with a hierarchy of Capability > Feature > Story. We're using Epics to represent Features. Capability is a new issue type in JIRA. Portfolio recgnises the hierarchy and this part works fine.
We have about 10 projects and have just completed planning for our first Programme Increment. If I report on all epics and stories, the total number across the portfolio is over 2000.
Having added the projects into Portfolio, I've found that we can't drill down to user story level as Portfolio reports "The next level of hierarchy is currently disabled. There are too many issues to load them all individually. Please use the filters to narrow down the data set first"
This seems to be quite a major limitation as surely the idea of Portfolio is to bring all of the data together, and we've hit the limitation already in our first sprint!
Questions are: What is the actual limit? Any tips on getting around this? Is this configurable? Surely there is not an expectation that stories are not viewed at Portfolio level?
Take a look at the Communities post How to confirm/limit the number of issues into Portfolio for a bit more information. In addition Live Plans set a hard loading limit. The current default is 2000 issues.
As you start having more and more issues in your plan, interacting with Portfolio becomes slower.
JIRA Portfolio tries to load all the issues which match the current filter. If it sees that a certain hierarchy level has too many issues, it will disable that level.
The best way to work around this would be to apply a filter on something the issues have in common, such as the project or release. This will reduce the total number of tasks allowing epics to be expanded.
At this point, you can use filters narrow down the issues they want to work with and this will allow you be able to expand the epics.
It is possible to change this value in Server. Though it should be noted that this can cause the UI to become slow and unresponsive. We won't be able to guarantee a seamless operation.
The instructions to change the limit are as follows:
Hopefully this helps.
The Cloud version has the 5000 issues limit as well. A way to workaround the issue limit is to reduce the number off issues you'd like to view in your plan. A good way to do that is either by creating filtered boards in Jira and source these boards to Portfolio or alternatively create custom issue filters in Jira and use these filters as sources for your plan. Check out this doc for more details: https://confluence.atlassian.com/jiraportfoliocloud/getting-started-with-portfolio-for-jira-873926170.html
I hope that helps,
Roi | Product Manager Portfolio for Jira | Server/DC
This is not an effective workaround for situations where you have already limited the plan to team boards. By using the issue filter only, you would be removing the capacity and velocity planning functionality. Large organizations need to be able to load more than 5000 issues.
I do understand though that organizations that are large enough to break the issue limit using just team boards are probably an edge case for Atlassian.
Never-the-less.....we still need to be able to load more than 5000 issues....otherwise we will have to look for a solution outside of Atlassian. Even if that means taking a performance hit.
By the way Harvey as a side note....we are also running SAFe with Atlassian.
I have found it easier to run 1 project per train....then have multiple team boards under each project. It displays better in portfolio as an aggregate view. Off-topic but I thought it'd be worth mentioning.