The scope view shows an overview of all the work comprised in your plan. It is composed of issues that are pulled from the project board or filter you used to connect your plan. The scope view consists of two main parts:
Schedule - The top half of your scope view that shows a visual roadmap of all work items in your plan.
Scope table - 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.
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.