Rolling up values to parent issues

Still need help?

The Atlassian Community is here for you.

Ask the community

For parent issues, you can choose to display a preview of the rolled-up values of the child issues in several fields in a plan. The rolled-up values will appear with a roll-up arrow icon beside them. Note that the rolled-up values are just a preview, and you can still change these values if needed.

You can roll up the following values: estimates, teams, sprints, and releases.

Sample plan with team values being rolled up, from child issues to parent issues

To enable roll-up values in a plan:

  1. In your plan, click the View settings drop-down.

  2. In the Roll-up section, select the Dates or Others checkbox, or select both.

Rolling up estimates in a plan

When issue estimates are rolled up from child issues to parent issues, note the following:

  • Rolled-up estimate values are rounded up to only one decimal place for story points, and two decimal places for hours and days.
  • The rolled-up value of a parent issue will display 0 if work has been logged for its estimated child issues, and there's 0 time remaining for the child issues.
  • If a child issue hasn't been estimated, its estimate field will remain blank. Since there's no estimate value, this won't have any impact on estimate roll-up on its parent issue.


Rolling up dates in a plan 

When roll-up dates are enabled, the dates of direct child issues will roll up onto the parent issue itself, if the following is true:

  • you haven't explicitly set a start date or end date for the parent issue, and
  • you haven't assigned the parent issue to a sprint.

Sample plan with teams and dates rolled up to the parent issues

In the sample plan above, you'll see the following:

  • Both team values and date values of child issues are rolled up to the parent issues, and the values are displayed with the roll-up arrow icon.
  • The parent initiatives and epics that don't have start and end dates, or both dates now display differently:
    • Initiative PM-1 now displays a roll-up date for its start date, with the roll-up arrow icon as well. Its schedule bar in the timeline appears differently, with the start date side displaying in yellow stripes, and the end date side displaying in solid yellow. This is because PM-1 has a rolled-up start date and an explicitly set end date. The schedule bar is colored yellow because the issues in the plan are colored by status.
    • Since epics IOS-9 and ADR-1 don't have explicitly set dates, then they're now displaying roll-up dates from their child issues. Their dates display with the roll-up arrow icon, and their schedule bars are displayed in stripes colored by status.
    • Since epic ADR-19 has an explicitly set start date but no end date, it now displays a roll-up date for its end date. Its schedule bar displays the start date side in solid blue, and the end date side in blue stripes.
    • Since epic ADR-18 has explicitly set start and end dates, the date values remain the same, and the schedule bar displays in solid blue.

How roll-up dates work

Roll-up dates function and adhere to the following:

Roll-up operates on the start and end dates used in a plan

Roll-up dates operate on the configured start and end dates of a plan. These are the dates that are being used to schedule the issues in the plan itself. These dates include the following:

  • Target dates, which are the default type of dates being used to schedule issues in a plan
  • Custom dates, as long as they are of the date picker custom field type, and have been configured to be the start and end dates in a plan. The custom date columns will be displayed with the date lozenge ().
  • Sprint dates, if the plan has been configured to use sprint dates for issues that don't have start and end dates. The sprint dates for each issue will be displayed with the sprint lozenge ().

Roll-up dates are consistently used as regular issue dates throughout Portfolio for Jira. This means that the dates are used all across the plan, from scheduling the issues in the plan to triggering warnings for any misaligned dates.

The story level is the lowest level where roll-up can happen

The sub-task level is the lowest hierarchy level in Portfolio for Jira. The story level is then the lowest hierarchy level where date roll-up from sub-tasks can then happen.

Sample roll-up of sub-task dates to story dates

In the example above, note the following:

  • The parent story ADR-2 has a child sub-task ADR-22.
  • ADR-22 has explicitly set start and end dates, which roll up to its parent story ADR-2.

Roll-up still happens even if a child issue doesn't have a start and end date

Even if a child issue has no start and end date, roll-up will still happen for its parent issue. The missing dates for that child issue will be ignored, and date roll-up will be based on the existing dates of the other child issues.

Note that for roll-up to happen in this situation, the parent issue must have at least two child issues, and one of them should have start and end dates. If all the child issues of a parent issue don't have any dates, roll-up will not happen. If a parent issue has only one child issue and it doesn't have any dates, roll-up will not happen as well.

Sample roll-up, with a child issue having no dates

In the example above, note the following:

  • The parent epic ADR-8 has child issues using sprint dates, from Android Sprint 1 and Android Sprint 3.
  • The child story ADR-9 is not assigned to a sprint, and is therefore not using any sprint dates. ADR-9 doesn't have any explicitly start and end dates as well.
  • Date roll-up still happens for the parent epic ADR-8. The missing dates of ADR-9 are ignored, and the roll-up dates are based on the start and end dates of the other child issues.

Partial roll-up may happen for parent issue dates

Partial roll-up can happen as long as one of the issue dates is not set, and there are two possible scenarios when this may happen.

When a parent issue has one date explicitly set and the other date is a rolled-up value

If a parent issue has one date explicitly set, and the other date is rolled up from child issues, then the schedule bar of the parent issue will display a partial roll-up.

Sample partial date roll-up, with explicitly set start date and rolled-up end date

In the example above, note the following:

  • The parent epic ADR-8 has child issues using sprint dates, from Android Sprint 1 and Android Sprint 3.
  • ADR-8 has an explicitly set start date, but its end date is rolled up from its child issue dates.

When a child issue has one date explicitly set and the other date is not set at all

If a child issue does have one date explicitly set, be this the start date or end date, then the schedule bar of the parent issue will display a partial roll-up, and the roll-up will fade out towards the side of the missing date. This missing date prevents Portfolio for Jira from determining a roll-up date, and thus the roll-up fades out.

Sample partial date roll-up, with a child issue having no end date

In the example above, note the following:

  • The parent epic ADR-8 has child issues using sprint dates, from Android Sprint 1 and Android Sprint 3
  • The child story ADR-9 is not assigned to a sprint, and is therefore not using any sprint dates. However, ADR-9 has an explicitly set start date, but no end date. The schedule bar on the timeline is displayed in solid blue at the start side, but the bar's color gradually fades out.
  • Partial date roll-up happens for the start date of the parent epic ADR-8. There's no end date value, but the roll-up icon still displays, to indicate that partial roll-up is happening. With the schedule bar displaying in roll-up stripes, the bar's colored stripes also gradually fade out towards the end date.

Child issue dates have an impact on rolled-up parent dates

If a parent issue has rolled-up dates, and you explicitly set the dates for one of its child issues, the dates of the parent issues will adjust accordingly but will still retain its rolled-up state.

Sample plan with parent epic having rolled-up dates

In the example above, note the following:

  • The parent epic IOS-9 has child issues using sprint dates.
  • The child issue dates roll up to the parent epic itself, which is why the its schedule bar is in blue stripes.

If we move the end date of IOS-17 to a later date, the following will happen:

  • IOS-17 now has a new end date of 6 Feb 2020.
  • The parent epic IOS-9 also inherits the new end date of 6 Feb 2020.
  • Since the parent epic's dates are rolled-up from its child issue dates, the schedule bar will remain in blue stripes.

Child issue dates have no impact on explicitly set parent issue dates

With roll-up dates enabled, the dates of child issues will no longer have an impact on the dates of its parent issues.

For example, if a child issue's end date goes beyond its parent issue's end date, the parent issue's end date will not be pushed out, and will remain as is.

Sample plan with parent epic having explicitly set dates

In the example above, note the following:

  • The parent epic IOS-9 has child issues using sprint dates.
  • IOS-9 has explicitly set start and end dates, specifically 7 Feb 2020 as its end date.
  • Even if roll-up dates are enabled, IOS-9 will be using the dates that have been explicitly set for it. This is why its schedule bar is in solid blue color.

If we move the end date of IOS-17 to a later date, the following will happen:

  • IOS-17 now has a new end date of 19 Feb 2020, which triggers a warning that the child issue end date goes beyond the parent issue end date.
  • Even if roll-up dates are enabled, the parent epic IOS-9 will still be using the dates that have been explicitly set for it.
  • IOS-9 will still have its end date as 7 Feb 2020, and its schedule bar will remain in solid blue color.


Roll-up dates respect the configured view settings in a plan

Roll-up dates respect the group and color settings that have been configured in a plan.

Sample plan with issues grouped by projects, colored by labels, and having rolled-up dates

In the example above, note the following:

  • The issues in the plan are grouped by projects, with the issues in the Android App project appearing in the top swimlane.
  • The issues are also colored by labels, with the schedule bars accordingly colored by the labels set for each issue.
  • The epic ADR-8 has two labels, design and documentation, so its schedule bar is displaying the colors set for both labels.
  • Because the dates of ADR-8 are rolled up from its child issues, the schedule bar is also displayed in colored stripes.

Last modified on May 1, 2020

Was this helpful?

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