Learn how to set up Jira Software Cloud and integrate it with other products and applications.
Learn how to configure your Jira Software Cloud company-managed projects to suit your agile development processes.
Learn how to create, search, and work with issues in software projects, manage your profile, and more.
Learn how to get started, enable features, and manage and administer team-managed projects.
Search for issues, navigate to your work, use advanced search, and work with your search results.
Plan and view work across multiple teams, projects, and releases using Plans.
This page refers to the advanced planning features that only available as part of Jira Software Cloud Premium and Enterprise.
We have a separate section for documentation about the project timeline that’s included in all Jira Software projects. Go to the documentation for project-level roadmaps in Jira Software.
your plan comes with tools specifically designed for long-term planning that don’t exist elsewhere in the Jira ecosystem.
Parent issue and child issue are relative terms used to refer to higher-level issues that contain smaller tasks. This concept scales to any hierarchy level:
an initiative (parent issue) that contains epics (child issue)
an epic (parent issue) that contains stories (child issue)
a story (parent issue) that contains subtasks (child issue)
In this documentation, we use initiative, epic, and story in examples to refer to hierarchy levels based on Agile best practices. However, in Jira Software, these labels can be configured by your administrator.
A big problem for planners is that what you plan isn’t always what ends up happening. Instead of forcing you to manually update values of parent issues, you can tell your plan to infer values of parent issues based on those of the child issues. This is referred to as a roll-up.
From the View settings menu on your timeline, choose either option to infer a value:
Rolling up dates is a calculation that only exists for planning purposes in your plan. When you commit changes back to your Jira issues, rolled-up values are saved as a static number or text as if they’re manually set. This value stored in your Jira issue will not dynamically update as your plan evolves.
For example, let’s look at the screenshot below:
The top level issue is an epic, and contained within are three stories. With rolled up values enabled, your plan automatically picks the earliest start date and the latest end date of the child issues, then applies them to the parent issue. This way, if the child issues get rescheduled, delayed, or removed from your plan (which happens; no judgement), the values of the epics automatically reflect this and keep your plan on track.
As your plan grows and changes, your plan will alert you to any errors in your plan by turning the row yellow, and adding a warning icon in the Scope column. These warnings indicate inconsistencies in your plan like misaligned dates, overlapping dependencies, missing sprint assignments, and more.
your plan can automatically schedule issues for you based on any information that you’ve already added like issue estimations, scheduled issues, dependencies, release and team assignments, and more. From here, you can either commit the plan as is, or use it as a starting point to make further edits.
Capacity and velocity
Capacity and velocity are two features that help you create efficient but achievable plans.
Capacity in your plan refers to the number of story points or hours your team can complete in one iteration. For example, a team with a capacity of 30 story points (which is the default setting) can contain six issues that are estimated at five story points each during one iteration.
Velocity, which only exists within your plan, is your team’s average capacity per iteration over time based on past performance. For example, a team with a velocity of 30 story points will require two sprints to complete an epic estimated at 35 story points, assuming no other work was already assigned to those sprints.
Together, these two features ensure that your plan is realistic based on how quickly your teams are able to work.
Was this helpful?