Portfolio for JIRA FAQs
This page refers to Portfolio classic plans. If you're using Portfolio 2.0 and later, please check this section for frequently asked questions about Portfolio live plans.
We have collected some frequently asked questions about Portfolio for JIRA. Select a category to see the questions and answers or view the top 10 FAQs below.
FAQ per topic
- ストーリー ポイント
- Backlog management
- Standard Plans Q & A
- Importing, syncing and updating
- Graphical schedule
- Prerequisites, permissions and setup
Top 10 frequently asked questions
Estimates can be made in story points or time based, see Estimating and managing time budgets.
- For scheduling, the focus shifts from individual resource scheduling to team-focused scheduling, with a velocity field and velocity forecast at the team level (either directly entered, or pulled from the available history from a team's Agile board). This also means, that entering individual people/resources will become optional, as teams are the unit of granularity relevant for the schedule.
- Progress tracking is based on the burndown of points, rather than time spent.
Themes represent specific business objectives. Ideally, themes focus on the key future differentiators. The reporting on themes helps to see how much time is spent for work that contributes to each of the themes, for example: it helps to check if the teams are focused on the actual, higher-level business goals or effort is spent elsewhere.
The general rule is that the lowest level entries in the hierarchy can only be assigned to one theme. Thus, stories can be assigned to one theme only. If an epic has several child stories assigned to different themes, the epic is then assigned to multiple themes. If an epic does not have child stories, it can be assigned to one theme only. Since we want to report on resource allocation it needs to be clear which theme an effort is assigned to (otherwise we’d have to start splitting up or double-counting effort towards multiple themes).
With Portfolio for JIRA, you can have one or multiple portfolio plans and each plan can be either cross-team/cross-project, or focused on a particular project. Within a plan, work items are structured into three actual levels of hierarchy:
Initiative > Epic > Story.
Below stories, you can have sub-tasks directly in JIRA applications. Subtasks are not explicitly represented in Portfolio, but they are considered for aggregated progress tracking and reporting. The structure is orthogonal to JIRA applications projects, so you can pull data from multiple JIRA applications projects into one portfolio plan. Additionally, the issues can be assigned to themes (which typically will represent higher-level business objectives or resource investment buckets). While themes are the highest-level items, they don't actually represent an extra level in the hierarchy since the items within an initiative can contribute to different themes.
Portfolio for JIRA allows you to import any issue type. The only explicit benefit of epics and stories is that their hierarchy is known and can be imported right away. When importing other issue types you will need to decide at which hierarchy level to import the issue (initiative, epic or story-level of the hierarchy) and select the parent item.
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 represent the level of granularity approved by and reported to top management. Initiatives don't have a direct, binding relation to JIRA applications projects. In many cases, the epics and stories grouped to an initiative live in multiple JIRA applications projects. In other cases, all the issues for an initiative might be in one dedicated project.
Yes it does, the data in Portfolio for JIRA is implicitly cross-project data, with issues originating from potentially multiple JIRA applications projects.
Portfolio for JIRA is designed to allow flexible planning, working in a protected sandbox environment until you are finished planning. When importing existing issues, a link is established, so progress and status information updates in real time from the linked issue. Planning changes (such as assignee, release version etc.) are not automatically pushed back, but can explicitly be synced by updating the links (Plan > Update linked Issues). In this way, you can create a copy of a plan, compare different scenarios and then selectively publish back to JIRA applications.
Status and roll-up progress is always up-to-date . Other changes such as resolving an issue or remaining estimates being changed don't automatically reflect in the plan. These require you to do an explicit update. The reason for this is to make it very transparent which changes are happening to your plan. By going to Plan > Update from date you will get a list of suggested changes (issues being completed, or remaining estimates being changed), which you then can confirm in bulk. When teams work in iterations, the recommendation is to do this update after each sprint to have an up-to-date view based on the work the teams have accomplished.