Cloud
Data Center 3.5
Versions

Configuring the scope view

Scope

On this page

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

This page discusses the usage of Portfolio for Jira live plans (any version from 2.0 to 2.27). If you're using the redesigned planning interface, see this page instead.

The scope in Portfolio for Jira is the global to-do list for upcoming releases for your work.

The scope is comprised of three (3) hierarchy levels by default:

  • Epics - Once higher-level priorities are settled, it's necessary to break them down into large pieces of work, which consist of multiple stories.
  • Stories - These are the user stories capture functionality requirements.
  • Sub-task - These are the work components that make up stories.

Though these are the default hierarchy levels, you can still create and customize unlimited hierarchical levels in Portfolio for Jira.

Viewing issues in the scope table

  1. Go to your plan via Portfolio (in header) > View Portfolio > click your plan.
  2. Click the Scope tab to display the scope table.
  3. From the hierarchy menu, click the hierarchy level for the issues that you want to display in the scope table.
  4. In the scope table, click an issue to view more details about the issue on the right panel that appears.
    Note that when you click an issue, that issue will also be highlighted in the timeline. 

The scope table displays the following issue details:


Issue detailDescription
1#Position or ranking of the issue in the scope table
2TitleTitle of the issue
3ReleaseRelease to which the issue is currently assigned
4EstimateTime estimate of the issue
5Original estimateOriginal time estimate of the issue, if any
6ProgressCurrent progress of the issue
7TeamTeam that the issue is currently assigned to
8MembersMembers of the team to which the issue is currently assigned
9SprintSprint to which the issue is currently assigned
10Earliest start date

The earliest date when work for the issue will start.


Read more about how the earliest start date works

The earliest start date is a constraint that guarantees that an issue is not scheduled before the date that you define. This applies even if the issue has a higher priority relative to other issues in the backlog, and even if there are free resources to work on that issue.

  1. Earliest start date set on a parent issue: By setting the earliest start date on a parent issue, all child issues will also be given the same earliest start date, which is 11th September 2017, in the example above. In practice, the child issues may even be scheduled a few days later, and may coincide with the beginning of the next sprint, if your team works in sprints.
  2. Earliest start date set on a child issue, with its parent issue also having an earliest start date: In this case, the date defined for the child issue overwrites the date of the parent issue. In the example above, even if MEX-13 (parent epic) has an earliest start date of 11th September 2017, MEX-4 (child issue) will still have an earliest start date of 25th September 2017.
  3. Earliest start date set on a child issue, with other child issues not having an earliest start date: In the example above, MEX-14 (parent epic) doesn't have an earliest start date set. However, its child issues MEX-3 and MEX-8 have individual earliest start dates set, and another child issue MEX-2 doesn't have any earliest start date. The individual dates then apply only to the corresponding child issues.
11Target start date

The date when work for the issue is targeted to start – this has no impact on schedule calculation

12Scheduled start date

The date when work for the issue is scheduled to start, based on the data provided in the plan


13Target end date

The date when work for the issue is targeted to be concluded – this has no impact on schedule calculation


14Scheduled end date

The date when work for the issue is scheduled to be completed, based on the data provided in the plan


15Initiative

Initiative to which the issue belongs to, if any.

If you're using the default hierarchy configuration in Portfolio for Jira, initiatives would only display if you're viewing issues at the epic level.

16Epic

Epic to which the issue belongs to, if any.

If you're using the default hierarchy configuration in  Portfolio for Jira, epics would only display if you're viewing issues at the story level.

17Label

Label assigned to the issue, if any.

Labels are usually keywords or tags that you can add to your issues, as a means to categorize work.

18Component

Component assigned to the issue, if any.

Components are usually sub-sections of a project. These are used to group issues within a project into smaller parts.

19ThemeTheme assigned to the issue, if any
20Issue status

Current status of the issue in the workflow.

By default, Portfolio for Jira considers an issue to be "completed" when it is assigned to any status of the "done" category.

21ProgressCurrent progress of the issue
22SourceThe board, project, or filter from which the issue is pulled from

Configuring the details in the scope table

You can choose which issue details to display in the scope table. This is handy when you just want to quickly view specific details about the issues in your plan.

  1. In the scope table, click .
  2. Click the issue details that you want to display in the scope table.

Troubleshooting

Why aren't issues appearing?

Try one of the following steps to make your issues appear in your plan:

  1. Make sure the fixVersion field is not hidden for that issue type.
  2. Check if there are any view filters configured for your plan that exclude the issues not appearing.
  3. The issues not appearing may not have been given a resolution value, such as unresolved.
  4. The issues may have already been completed.
  5. The issues may be within a release that's excluded from your plan.
  6. The issues were manually excluded when creating your plan. For instance, when you exclude an epic during plan creation, the child stories of that plan are also excluded.
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 won't be applied when creating issues.

We're working on a solution for this, but for now, we recomend you use an agile board for your filter, and then initially create your issues on that board. In most cases, the required filter values will be automatically added to the issue.

I don't see closed 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."

For example, in your plan, go to More > Completion date.

Related topics

Last modified on Jan 6, 2020

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.