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
- Go to your plan > Scope.
- 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:
- 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 dependenciesYou can use the earliest start date to account for an external dependency that is not tracked in Jira Software. Example:
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.
| ||||||||||||||||||
| 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.