Frequently Asked Questions
What defines a plan start date?
- If there is an active sprint in your plan, the earliest date of all your sprints will be picked up as the start date. You must have teams connected to agile boards for that.
- If you don’t have active sprints then, the earliest fixed release date of your plan releases will define the earliest start date of your plan. Portfolio looks at releases in order. We look at the first release of every project that has a fixed start date and we pick the earliest of them.
- If you have 2 projects, we look at the first release that has a fixed start date for every project and take the earliest of these.
- If there are no sprints or releases matching the first two rules, Portfolio uses "today" as the plan start date.
Are plans considered fiscal plans or individual projects?
Plans are flexible and can be used at different levels, according to your way of working. You might make different plans for different departments, create a separate plan for the next quarter, or make plans for a particular set of projects. We recommend keeping plans distinct from each other and avoid sharing data between them, such as resource availability. Whenever you need to balance resources between projects and teams, put the data into one plan. If areas of work are completely independent, use separate plans.
What is the functional purpose of an initiative versus a release? How does it relate to Jira projects?
An initiative groups epics and stories into larger chunks of work. Initiatives typically span multiple releases, with intermediate deliveries along the way. Business initiatives typically encompass substantial scope and investment, and represent the level of granularity approved by and reported to top management.
Initiatives don't have a direct, binding relation to Jira projects. In many cases, the epics and stories grouped to an initiative live in multiple Jira projects. In other cases, all the issues for an initiative might be in one dedicated Jira project.
Is there a separation between dynamic planning and the commitment of those changes?
In Portfolio for Jira, you can play with different scenarios before deciding to commit changes back to Jira Software. The total number of changes made in your scenario is indicated in an orange bubble at the top of your plan.
You can confirm changes by committing them to your Jira Software application, or discard them by reverting them.
How can I ensure I have capacity for solving bugs and support questions considered in my roadmap?
Teams usually dedicate some of their time to fix bugs and support cases. This work load changes over time and allocating future time to it can be difficult.
Imagine that your team dedicates 80% of their time to roadmap work and a 20% to bug fixing and support. When you plan future sprints, the 20% bug fixing time won't be allocated and Portfolio will assign 100% of the team capacity to roadmap work.
You can ensure you have capacity time for support and bug fixing in your roadmap by following these steps:
- Reduce your team velocity in your Portfolio plan to represent your 80%.
- Identify the boards you want to use in your plan.
- For each board, create a filter that excludes the unwanted issues (bugs in this case).
- The filter would look something like this: Filter = "Filter for XYZ Board" AND issueType NOT IN ("Bug")
- These filters only need to be shared with the plan users.
- Create boards based on those filters.
- The new boards automatically get the same sprints as the original boards and you won't need to create sprints twice for every board, the only difference will be the bugs being filtered out.
- Create or update your plan with those new boards.
Why are issues not appearing?
There are several reasons your issues may not appear in your plan:
- Make sure fix Version field is not hidden for that issue type.
- There are view filters set in the portfolio plan that exclude it:
- The issue is has not been given a resolution value (e.g unresolved).
- The issue has been completed.
- The issue is within a release that has been excluded.
- The issue was manually excluded in the start up wizard. Excluding an epic excludes its child stories.
I don't see certain issue types in my plan.
This is currently a problem with issues that are created and committed for particular issue sources. If the issue source is a filter or board and the queries used for that source require a specific field value, then that field value will not be applied on issue create. We're working on a solution for this but for now the recommendation is use an agile board for your filter and initially create your issues there. In most cases the required filter values will automatically be added to the issue.
I don't see completed issues in my plan.
This can happen if there is no active sprint. To fix this, change the "Completion date" filter to something other than "Current sprint"
Go to your plan > More > Completion date.
How do I import new issues into my plan?
Portfolio doesn't exactly "import" issues, but lets you set projects/boards/filters as an issue source so that any new issue added to those sources from Jira get automatically added to your plan.
How do I add initiatives?
Initiatives are still possible to use in Portfolio but due to the new integration functionality, Portfolio 2.0 requires you to configure new levels of hierarchy and link the new levels to an issue type in Jira.
How do I add issues to a sprint in Jira Software?
You can assign issues to a specific sprint in Portfolio but it requires a small amount of configuration and only works for "Board" issue sources.
Can Portfolio be used for teams that don't use sprints? How can it help Kanban or waterfall teams?
Yes. it's possible that some teams work in Scrum mode, and others in Kanban or with traditional methodologies. Common to both modes is that the scheduling algorithm always focuses on finishing individual work items completely before starting new ones. For example, when your team starts designing a feature, Portfolio schedules its implementation to start before designing another feature.
Can multiple users be assigned to the same story through Portfolio for Jira?
Yes. Portfolio allows multiple assignees on stories. You can change the maximum number of assignees to a single story in the settings.
Can Portfolio for JIRA suggest the best teams to assign to an initiative based on the schedule?
If you don't assign a team manually, Portfolio automatically suggests teams who can deliver the initiative the fastest.
How do I model a release sprint, regression or stabilization effort?
There are two ways:
- Put a placeholder epic with an effort estimate to represent the stabilization's effort. You could size it so it fills out the capacity for a full-time sprint. You might have to work with dependencies or an earliest start date to ensure the capacity is reserved only after the other work is done.
- Modify the start date of the next release to leave a time buffer in between, for example, the subsequent release starting 2 weeks after the end of the previous release.
Any plans for sprint capacity planning? I'd like to know where my resource bottlenecks are during a given two-week iteration. Jira doesn't do that natively and as a result I have to create a capacity plan in Excel.
Jira Portfolio should be able to help you with that today. It might be a bit counter-intuitive since you work in sprints, but in order to plan exact capacities on a day to day basis you would have to switch the team to Kanban mode (in the people section, team schedule column). You could use releases to represent sprints instead. This will give you a day-to-day plan within your sprints to see how people are allocated.
Does Portfolio have exporting available for reports?
We currently have CSV exports available for the scope and releases. To download a CSV, go to the particular report and click the export button located on the right.