So far you’ve been able to use releases to group features into concrete releases based on sequential numbers (R17, R18, R19), broader time horizons (Jan release, Feb release, March release), or relative time frames (Now, Next, Later...).
Now you can add start and end dates to releases and visualize them along a timeline! This will help you clearly see what’s being worked on sequentially or at the same time, and what’s expected to be delivered when.
We recommend using this new Releases on timeline style of roadmap when planning internally with your team, especially when aligning on dependencies and team allocation. To communicate your plans with the rest of your colleagues we recommend using objective-driven roadmaps instead, which can be more helpful in rallying everyone around the outcomes you're trying to achieve.
And whenever dates are involved, be sure to set the right expectations with stakeholders, particularly when planning different contingencies far in advance! It's one thing to map out different what-if scenarios for working on various releases over certain time horizons. It's another for those preliminary plans to be interpreted as concrete commitments! (This is rarely helpful when you want to be able to adjust your plans in an agile manner based on what you learn along the way). If in doubt, limit sharing access to these roadmap views.
Add existing releases directly to your roadmap or create new ones on the fly.
Drag and drop releases to adjust their order or sequence in time. Adjust their endpoints to signify their duration and when they might be worked on.
All features assigned to the release will appear beneath it on the roadmap.
Features appearing beneath releases can also be hidden from roadmap configurations.
To add features directly to a release, ensure features are configured to appear on the roadmap. Then select the + icon beneath the list of features under the release.
Multiple teams and release groups
You can visualize releases from different release groups on the same roadmap view. This could be helpful for seeing how two different teams' releases stack up, particularly if there are dependencies between what they’re working on.
However, releases from different release groups aren't yet distinguished with swimlanes or other visual cues. Adding a prefix to release names may help distinguish them for now.
Dependencies can be noted informally but cannot yet be visualized.
- If you've named existing releases to contain dates, months or other time ranges, there’s no existing way to automatically map these to the timeline. It will be necessary to assign these releases dates just like any other release.
- It’s not yet possible to sync a release's start and end dates with Jira.