Frequently asked questions (live plans)
The content in this page pertains to the usage of live plans in Portfolio for Jira.
A plan can be used at different levels. There is no general rule to using plans – how you use plans would typically depend on how you work. You might make different plans for different programs, create a separate plan for the next quarter, or make plans for a particular set of projects. The only rule is that plans are logically separated, and should not share any data, such as resource availability. This means whenever you need to balance resources between projects and teams, put the data into one plan.
イニシアチブとリリースの機能面での目的は何ですか? どのように Jira プロジェクトに関連するのでしょうか?
An initiative groups epics and stories into larger chunks of work. Initiatives typically span multiple releases, with intermediate deliveries along the way. Business initiatives will typically encompass substantial scope and investment, and will thus likely 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 changes?
In Portfolio for Jira, you can play with different scenarios before deciding to commit changes back to Jira. 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 Jira, or discard them by reverting them.
The issue 'x' doesn't appear in my plan
Make sure that:
- the fixVersion field is not hidden for that issue type.
- there are no filters set in the portfolio plan/setup wizard that are excluding it
- the issue is has not been resolved otherwise It won't be visible in the import wizard.
- if you are in plan view, go to More > status > open and completed issues and/or More > status > completion date.
- the issue is not within a release that has been excluded.
- the issue was not manually excluded in the wizard.
Portfolio for Jira 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 are automatically added to your plan.
Initiatives are the high-level priorities that multiple teams or departments work against in an organization or company. Initiatives can span multiple epics, projects, and teams, and the work for initiatives can last months and even years. Using initiatives is essential in Portfolio for Jira, so you'll need to configure these in your plan hierarchy.
How do I add issues to a sprint in Jira?
You can assign issues to a specific sprint in Portfolio for Jira, but it requires a small amount of configuration and only works for "board" issue sources.
I need to manage a mixture of teams that use Scrum and Kanban. Can I still use Portfolio for Jira?
Yes, Portfolio for Jira can support a mixture of teams that use Scrum and Kanban. Common to both methodologies is that work on issues must be finished completely before starting work on news ones. If there's sufficient capacity to work on multiple issues, then this will also be reflected accordingly.
Portfolio for Jira で 1 つのストーリーに複数のユーザーを割り当てることはできますか?
Yes, Portfolio for Jira lets you assign multiple users to the same story. The maximum number of people that can be assigned to a single story is configurable in the settings.
Can Portfolio for Jira suggest the best teams to assign to initiatives based on the schedule?
If you don't assign a team manually, Portfolio for Jira will make an automatic assignment, and suggest the teams who can deliver the work the fastest.
How do you model a release sprint, regression, or stabilization effort inside a release date being calculated?
There are different options to achieve this goal.
- Put a placeholder epic with an effort estimate to represent the stabilization effort. You could size it in such a way that it fills out the capacity for a full time for a sprint. You might have to work with dependencies or an earliest start date constraint to ensure the capacity is reserved only after the other work is done.
- Another approach is 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 two-week iteration. Jira doesn't do this natively, and as a result, I have to create a capacity plan in Excel.
Portfolio for Jira 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 for Jira support exporting 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.
Please refer to Scheduling and timeline for more information about this topic.