Plans & Timelines
Overview
Jira includes two ways to for teams to use gantt charts to visualize their work’s progress over time: “Plans” and “Timelines”. With a bit of work, both can help you:
Manage dependences
Visualize your schedule
Predict the impact of changes
Things to Know Before You Start
Plans vs Timelines
Both “Timelines” and “Plans” both show a hierarchy of work in a gantt chart style view, and there was even a time when Atlassian called them “Plans” and “Advanced Plans”. However they do have different focuses which come with some important distinctions:
Timelines
Lives in a Jira Software project (all tiers).
Designed to help teams visualize their work.
Can only see issues which live within that project.
Plans
Lives at the instance level (Premium and Enterprise only)
Designed to show work of many different shapes (SAFe program increments, team\team-of-team roadmaps, waterfall projects, etc.)
Can include work from any combination of Jira projects, Agile boards, or filters.
How Strong is Your Data Fu?
These tools are the scions of a long line of attempts to solve the “large-scale planning” challenge, but none have really caught on. While there are probably many reasons for this, I would say the core problem is that:
The value of these tools exists when the majority of the data they need to operate is both present and accurate.
These tools need a lot of data and keeping them present and accurate can have a correspondingly high maintenance cost.
Most of what drives gantt charts is dates, and no matter what else you report on, you will likely have issues there. Particularly in “Plans” however, you may find the same issue cropping up around other important information.
Using tools like Automation and Dashboards, you can mitigate a lot of the maintenance costs needed to make these tools useful.
Getting Started
Automate Your Fields
Use Sprint Start and End Dates for Standard Issues
At minimum, your issues will need start and end dates if you want to see anything on the visualizations. Both tools can technically use sprint start and end dates if they’re set, however there are some limitations with this approach, particularly in Plans. Using an Automation rule to push the sprint dates into custom fields can eliminate most of them while enabling them for use in other areas like dashboards.
Rolling Up Start and End Dates for Parents
Using an Automation rule to push child start and end dates up to their parents can help teams get a better sense of when larger chunks of work are fully planned and help stakeholders keep track of delivery date updates.
Sync Changes Up and Down the Hierarchy
There are times when you can use Automation to push data up or down the work breakdown structure. As example:
If an epic’s “Risk” field is set to “red”, you can update it’s parent initiative’s “Risk” field.
If an initiative’s priority is set to “High”, you can set the “Initiative Priority” field on it’s child epics to “High”.