Configuring initiatives and other hierarchy levels

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.