Configuring the scope table

The scope table is the bottom half of your scope view that displays the core to-do list of your plan. In this section, you can create new issues, add estimates, and view other associated information such as assigned releases. 


Levels of hierarchy

All information in the scope view can be viewed and filtered by issue hierarchy levels. The three levels of hierarchy by default are:

  • Epics - An epic is typically a very large user story, that is expected to take multiple sprints to complete. An epic is broken down into multiple stories, and is represented as an issue type in Jira.
  • Stories - A story is a small body of work that represents a product requirement. Multiple stories can be used to make an epic.
  • Sub-task - A sub-task is a unit of work contained within a story. It can be created to either split the issue into smaller chunks, or to allow various aspects of an issue to be assigned to different people.

You can also setup custom levels of hierarchy above the epic level such as initiatives.

  • Initiative - An 'initiative' is a very large body of work, which spans multiple epics and sometimes, multiple teams. Initiatives can be re-named to match a specific agile framework of an organisation. An initiative is also an issue type in Jira.

Learn how to create new hierarchy levels.

How to switch the hierarchy level view

  1. Go to your plan > Scope.
  2. Click the current hierarchy level and choose from the dropdown. 
    In some cases, issues of hierarchy levels that live above the one selected in the switcher are shown in the schedule. 

    For estimated issues:
  • Issues of higher levels that don't have children but are estimated.
  • Issues with an estimate and estimated children. When an issue has an estimate, Portfolio tries to schedule it. If it gets scheduled, it's shown in the schedule. Portfolio deliberately show these issues because it could otherwise result in blank gaps in the schedule.
    Example:
    Story 1 is scheduled in the first sprint: Epic A (does not have children, but is estimated) is scheduled in the second sprint, Story 2 is scheduled in the third sprint: If we didn't show Epic A in the schedule when viewing the plan on story level, there would be a gap in Sprint 2 that would be inexplicable b/c the context is missing. Therefore, estimated issues that get scheduled from higher levels "fall through" to all lower levels.

    For unestimated issues:
  • When an unestimated issue without children gets scheduled, its duration can be derived from either release, sprint or target dates.
  • When the unestimated issue gets scheduled, and it has children that don't get scheduled.


Before you begin:
  • Make sure the Fix Version field is visible in Jira Software before you get started. Any Jira issues with a hidden Fix Version field won't show in your Portfolio plan.
  • Ensure all your work items are estimated. Unestimated issues won't appear in your schedule. If you don't have estimates for all your issues, you can get Portfolio to automatically set default estimates for unestimated issues.

Steps to configure the information you see in the scope table

You can configure your scope table following these simple steps:

  1. Go to your plan > Scope > cog at the top right of the scope table.
    The dropdown displays the list of available scope table fields to choose from.

Select the table fields from the dropdown that you want to see on the scope table. In the following table, you can find the definitions of each table field.

Field Description
Title Issue title.
Releases Releases the issue is assigned to. A release is a set of features and fixes released together as a single update to your product. In Portfolio, a release can also be viewed as a milestone.
Story Points / Estimates (h) / Estimates (d)  Estimate assigned to the issue. Depending on your estimation unit, you'll see one or the other.
Earliest start date

A user-specified date that is the earliest possible date an issue can be scheduled to start on. Click on the link below for further details on the earliest start date.

This user-specified date guarantees that an issue will not be scheduled before a defined date, even if it has higher priority than other issues, or there are free resources available. 

Tip - Use earliest start date to account for external dependencies

You can use the earliest start date to account for an external dependency that is not tracked in Jira Software. Example:
You've outsourced the user research and design work for a product to an external vendor. You know you can't start development until this work has been completed by the external vendor and handed over to your development team. However, because they're an external team, you can't track their progress in Jira. This means that you can't add the external vendor's work as a dependency in Portfolio. Luckily for you, you know the completion date for the external vendor's work - 16/Oct/2016. You can use the external vendor's completion date to set the earliest start date for your team's development work. This earliest start date acts like a dependency, dictating that your team's development work can't be started until after the user research and design work has been completed by the external vendor. In summary:

  • If the external vendor's user research and design work is scheduled to be completed by 16/Oct/2016;
  • Set the earliest start date of your team's development work to 17/Oct/2016.

How does setting earliest start date on issues at various levels of your plan's hierarchy effect associated issues?

For example, If you set the earliest start date on an epic, how does it relate to the stories within it?

The following points refer to the three earliest start dates pointed out in the scope table screenshot above.

  1. Setting earliest start date on a parent issue: The earliest start date assigned to the parent (e.g. epic) applies to all stories within the epic. In the screenshot above, all the stories for epic IOS-1 App Basics - iOS will inherit the epic's earliest start date. Therefore, all the stories below the epic will only be scheduled by Portfolio from 17/Oct/2016 at the earliest.
  2. Setting earliest start date on a child issue where the parent already has the earliest start date set: Setting an earliest start date on a child issue (e.g. story) will overwrite any earliest start date set on its parent issue. In the screenshot above, story IOS-3 Setup dev and build environment has had the earliest start date set to 25/Nov/16. This differs from the earliest start date for its parent epic, IOS-1 App Basics - iOS - 17/Oct/16. Therefore, Portfolio ignores IOS-3 Setup dev and build environment parent epic's earliest start date and instead uses its story-specific earliest start date of 25/Nov/16 when scheduling. All of the other stories within the parent epic haven't had specific earliest start dates set, so Portfolio will continue to use the parent epic's earliest start date of 17/Oct/16 for scheduling. In summary, the following are the earliest start dates set for each of the stories within the IOS-1 App Basics - iOS epic and used by Portfolio for scheduling:

    Story Earliest start date
    IOS-2 As a user I can log into the system via Face... 17/Oct/16
    IOS-3 Setup dev and build environment 25/Nov/16
    IOS-4 Establish basic app dev framework 17/Oct/16
  3. Setting earliest start date on a child issue where the parent has no earliest start date set: If an earliest start date is set on child issues (e.g. story) where the parent issue (e.g. epic) doesn't have an earliest start date, the earliest start date will only apply to the specific child issue. The parent issue and other child issues will not be influenced by the specific child issue's earliest start date. In the screenshot above, the earliest start dates set on the stories, ADR-2 Establish basic app dev framework and ADR-3 Setup dev and build environment will only apply to these two stories. In summary, the following are the earliest dates for the parent epic, ADR-1 App Basics - Android, and each of the stories within it:

    Epic/Story Earliest start date
    ADR-1 App Basics - Android Not set
    ADR-2 Establish basic app dev framework 30/Nov/16
    ADR-3 Setup dev and build environment 01/Dec/16
    ADR-4 As a user I can log into the system via Fac... Not set
Target start date Configured target start date.
Scheduled start

The scheduled start date of the issue calculated from the provided data.

Target due date Configured target due date.
Scheduled end

The scheduled end date of the issue calculated from the provided data.

Team A group of real and virtual Jira users. Portfolio teams are defined by the amount of work they can get done during a given time period. Teams are the resource element of your plan.
Members A real or virtual user in Jira that is part of a Portfolio Team. Team members can have an individual capacity, calendar availability, and skills assigned to them.
Sprints Team members assigned to the issue.
Initiatives

A very large body of work, which spans multiple epics and sometimes, multiple teams. Initiatives can be renamed to match a specific agile framework of an organization. An initiative is also an issue type in Jira.

Labels

A label can be added to issues to categorize and group related issues.

Components A subsection of a project. They are used to group issues within a project into smaller parts.
Themes High-level strategic focus areas, value streams, or investment categories used to set priorities and define where teams will devote most of their time. Assigning themes to issues in your plan is great for stakeholders to see where the organization is spending time vs. what was planned.
Issue status

Represent the position of an issue in its workflow in Jira. Portfolio considers an issue Completed when it is assigned to any status of the Done category. For example, the green category.

Progress Issue progress bar. Learn more about tracking progress and status.
Source Where the issues were pulled in from. A Jira board, project, or filter is where all the issues in a user's Portfolio plan come from. Any change that a user makes to an issue which is within a connected issue source (e.g. create, delete or edit an issue) will be reflected in their plan when the page is refreshed or reloaded. Any change that a user makes to an issue in Portfolio's sandbox environment (e.g. use the scope table to create, delete or edit an issue) will only be reflected in their Jira issue source once these changes have been committed back to Jira.

Reordering the scope columns

You can reorder the scope columns by dragging the column you want to move and dropping it in a different place.

You can't move the members and sprints columns.



Last modified on Feb 1, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.