Scope report
The scope displays the core to-do list of your plan. I.e. all the work items in your plan. In this section, you can create new issues, and add and view other associated information such as estimates, releases, etc.
- Epics - Large bodies of work comprised of multiple Stories.
- Stories - Small bodies of work that represent product requirement. Multiple stories can be used to make an Epic.
- Sub-task - Work components (i.e. tasks) that make up Stories.
You can configure your scope view following these simple steps:
- Go to your plan > Reports > Switch report > Scope.
- Select the elements that you want to see in the scope columns.
Now you can see the selected elements in the main scope view.
Select the drop-down menu located on the right-hand side of the scope view to change which hierarchy level is being displayed.
| Title | Issue title. | ||||||||||||||||||
| Releases | Releases the issue is assigned to. | ||||||||||||||||||
| Story Points / Estimates (h) / Estimate (d) * | Time estimate assigned to the issue. *Dependent on your chosen estimate type, you will see one of the three fields listed in the field column to the right. | ||||||||||||||||||
| Original Story Points / OriginalEstimates (h) / OriginalEstimate (d) * | Field used to store your originally planned estimates. If the original estimate assigned to an issue is changed over time, use this field to gain a historical reference of the original estimate. *Dependent on your chosen estimate type, you will see one of the three fields listed in the field column to the right. | ||||||||||||||||||
| Earliest start date | The earliest start date refers to 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.
Click here to learn more about 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 relative to other issues, or there are free resources available. Tip - Use "earliest start date" to account for external dependencyYou 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 for the build. However, because they're an external team, you can't track their progress in JIRA - meaning you also can't add the external vendor's work as a dependency in Portfolio. Lucky 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 - earliest start date of 17/16/2016 date to set the earliest start date. This earliest start date essentially acts in the same way as 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:
How does setting earliest start date on issues at various levels of your plan's hierarchy effect associated issues?E.g. If I 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 | The date you’ve targeted to commence working on the issue. It has no impact on schedule calculation. | ||||||||||||||||||
| Scheduled start | The scheduled start date of the issue calculated from the provided data. | ||||||||||||||||||
| Target end | The date you’ve targeted to conclude work on the issue. It has no impact on schedule calculation. | ||||||||||||||||||
| Scheduled end | The scheduled end date of the issue calculated from the provided data. | ||||||||||||||||||
| Team | Team name | ||||||||||||||||||
| Members | Team members | ||||||||||||||||||
| Sprints | Team members assigned to the issue. | ||||||||||||||||||
| Start date | Sprint start date | ||||||||||||||||||
| End date | Sprint end date | ||||||||||||||||||
| Initiatives | Initiatives are groups of epics. Think of them as higher-level business priorities or big projects potentially spanning multiple teams. | ||||||||||||||||||
| Labels | Labels are keywords or tags that you can add to your tickets to categorize. | ||||||||||||||||||
| Components | Components are sub-sections of a project. They are used to group issues within a project into smaller parts. | ||||||||||||||||||
| Themes | Show the themes assigned to each issue. | ||||||||||||||||||
| Issue status | Portfolio considers an issue "Completed" when it is assigned to any status of the "Done" category. For example, green category. | ||||||||||||||||||
| Progress | Issue progress bar. Learn more about tracking progress and status here. | ||||||||||||||||||
| Source | Source where the issues were pulled in from. |
