Table of Contents

Introduction

In Jira it's possible to plan work on a timeline. This feature is called Jira Plans, (previously Advanced Roadmaps) and can be found in the top bar under "Plans".


The template Plans looks like this, allowing teams to plan their work per quarter and report out to management easily:


Access

Every logged in Jira software user can view Plans. Only those with specific Jira Plans access will be able to edit Plans. 

If you want to have a Plan created for your team, you can request one through a Service Desk ticket. You will then receive a template Plan and Jira Plans edit access.


Plans View

Plans has a range of options/actions and settings to create and manage a plan


(1) Manage your view

(2) Modify your view

(3) Issues in your plan

(4) Issue values in columns

(5) Timeline schedule bars, dependencies, and releases

(6) Clean up your plan and save changes in Jira



Template settings

In YME Jira we use a template filter that selects the following data per team:

"Yamaha Team" = TEAM OR "Yamaha Team(s)" = TEAM ORDER BY Rank DESC

Note: Only if the team is able to set this same filter as their scrum board filter, Roadmaps will unlock Sprint Planning features.


The following data can be set as excluded in Plans configuration:

It's recommended to use your Board to fill/correct the Basic View fields:

  • Correct the status
  • Set the T-Shirt size, to a number that has meaning relative to other epics
  • Target Start and Target End, to compile the visual timeline

Note: if you use the Progress bar, it will calculate based on underlying items, excluding anything completed longer than XX days ago. The exclusion rules can be found under the configuration of Plans Settings.


Use of the "Basic view" and "Dependency view" is supported. "Top level planning" and "Sprint capacity management" are not supported at this time.

Populating the Dependency view will enable the Dependencies report.


The following custom fields will be made available for use in Roadmap filters and fields:

Note is a field specifically used for Roadmaps, to easily note and read comments about progress, roadblocks, or dependencies.

Hierarchy

The Hierarchy for Plans, project items are grouped into hierarchy levels based on Issue Types.
For YME Jira the following Hierarchy has been setup:
 
Level 1-3 is used for Portfolio planning:

Level 1: Capability (YNSEU)
Level 2: Programme (YPM) , Strategic Theme  (YPB), Milestone (YNSEU), 
Level 3: Initiative (YPB) , Feature (YNSEU), Project (YPM)

All others levels are used in Jira Software projects.

Story level = Story, Enable Story, Task, Spike, Bug, Defect and for Jira Service Management Incident, Service request, Service request with approvals etc.


Hierarchy linking is done through epic link or parent link. You cannot skip a level so an epic must always be linked to a Initiative, Feature or a Project.


The Hierarchy can be manually selected for Teams,  the Basic View is Epic to Story level:

The Plan allows filtering, where a selection of multiple filters results in an AND statement. So selecting Team (Yamaha Team/ Yamaha Team(s) = Awesome and selecting Assignee = John, means that both statements need to be true.


Review changes

If you make any changes in Jira Plans, these are not automatically saved into the Jira database.

You need to Review Changes made in the top right corner to clean your plan, once you are happy with your plan and wish to commit it.

If you do not Review Changes  of your plan the data on your Board will differ from your Plan. 

Edit Issue Permission for Jira issues in the relevant project is required to be able to save the changes in Jira.


It's possible to drag and drop items, to change the relative rank between items, or to create issue links.

When you move a Story underneath an Epic, the Epic Link will be created on the Story (after Reviewing Changes).

When you move an Epic underneath a Project, the Parent Link will be created on the Epic (after Reviewing Changes).


Dependency

Dependencies show the relationship between issues in your plan, such as contingencies and blockers.
The following issue link type will be treated as dependencies in plans.

Blocks
Incoming dependency:  blocks
Outgoing dependency:  is blocked by


Defect
Incoming dependency:  defect of
Outgoing dependency:  has defects

Dependency
Incoming dependency:  Dependency from
Outgoing dependency:  Dependency to

 

View dependencies in the Dependencies report tab



Manage your decencies under the Dependency Management view.


Further reading

Atlassian documentation 

  • No labels