Configuring releases
This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.
You can define releases by creating them directly in your plan, importing them from a project, or linking existing releases to existing versions.
The release view has the following properties:
| # (rank) | Determines the order in which the releases are scheduled. Higher-ranked releases have priority for resource assignments. |
| タイトル | Release name as shown in the graphical schedule, drop-down fields etc. |
| 色 | Assign a color to the release stream for easy identification in the backlog graphical schedule. |
| Short Name | An abbreviation or logogram for the release; it can be used for the version number as seen in screens below, but also for a textual shortcode. |
| Version link | Allows you to see and assign a release to a version in a project. |
| 開始日 | Date when the first items can be scheduled for this release. Can either be a fixed date, or relative to the release date of a previous release. |
| 終了日 | The planned or forecasted end date for a release. Can be fixed, or forecasted dynamically based on the desired scope. |
| スケジュール作成 | An info column showing the scheduling mode, depending on whether a fixed or dynamic release date has been selected. |
| Assignable Team | Specify which teams are set to work on specific release streams so that the automatic scheduler will correctly assign the right team to the right projects. |
How to create a release stream
A stream is composed of a set of issues and associated releases; It's delivered on its own release cadence.
For example: In the following screenshot you see that the "Core Product" work stream is divided into two different releases.
Create a new stream by following these instructions
- Select your plan and go to Releases.
- Create a release stream by selecting + Create Stream.
- Select a stream color and a short name.
- You can delete a stream anytime by selecting the X button next to the stream name. If you delete a stream, you can still move the backlog items to a different stream.
Streams use cases
- Multiple products or products lines: When developing multiple products, each product or product family may have it's own stream of releases.
Release streams are used for two product lines (A and B). If the releases are not coupled to each other and exist in separate release streams, then product A and product B can be worked at the same time (depending on team capacity). In the graphic schedule, release streams are split so that it is easy to visualize activities running in parallel on the two product lines.
- Parallel projects: When planning for parallel projects with separate milestones, commitments, and end dates; each project can be scheduled in an independent release stream.
- For example: The image below shows the use of release streams for individual customers with parallel projects being planned for each one. Each row in the graphic schedule displays the activities for a single customer.
How to assign a team to a release stream
You can set a team to be dedicated to a particular release stream so that when the schedule is calculated that team is auto-assigned to backlog items within that stream. The auto team assignment based on streams can be overridden by manually selecting a team from the Assignable Teams list.
- Select your plan, go to Releases and locate the stream.
- In the Assigned Teams column, select the team or teams from the drop-down list.
- Click Apply.
How to assign backlog items to streams
Once streams are defined, backlog items can be assigned to streams and releases within these streams. The release selection cell indicates both the assigned stream and the version within the stream.
- Select your plan and go to Releases.
- Locate the item and go to the Release column.
- Select the version from the drop down list or click Calculate to allow the item to be auto-assigned to a release in that stream.
Release streams on the graphical schedule
The graphical schedule offers several options for working with release streams.
- Timeline per stream: Splits up the view into separate lanes/timelines per stream. This is helpful to see which activities are planned for each stream over time.
- Coloring by streams: Colors the epics and stories by the user configurable color selected for the associated release stream.
The releases view reflects the streams as well, and shows summary cards for each release in each stream:
How to create a release
In Portfolio for JIRA, a release is a set of work pieces called issues that are scheduled to be completed at a planned point.
- Select your plan and go to Releases.
You can create a release within a stream or if you're using a blank plan, you can create a release as the main chunk of work. - Create a release by selecting + Create Release. The Scheduling is set to dynamic by default. You can add a fixed start and end date by configuring the following fields:
| 開始日 | 説明 |
|---|---|
| できるだけ早く | リリースは利用可能なリソースがあるタイミングでできる限り早く開始されます。 |
| 固定日 | リリース開始日は固定日に設定されます。 |
| 前のリリース日と関連付ける | このオプションでは、前回のリリースが終了してから新しいリリースを開始するまでの時間差を指定できます。 |
| 終了日 | 説明 |
| 固定日 | リリース終了日は固定日に設定されます。可視化されたスケジュールでは、キャパシティがある場合にはバッファが表示され、キャパシティが不足している場合は赤色として表示されます。 |
| 動的リリース日 | リリースの終了日は動的に設定されます。スケジューラーは優先度に基づき、可能な限り多くの項目をリリースに自動的に含めます。リリースのキャパシティが不足することはありません。 |
Overlapping releases
In many cases it is helpful to define an overlap between releases. In practice, very often even if a story is scheduled for the next version, the UI/UX Design might be completed while the previous release last feature are still in implementation or testing.
An overlap generally has the semantics of "can start up to .. before the previous release ends".
For example: The actual work for the second, overlapping release is only started if there are free, unused capacities that are not required for the earlier release. In the screenshot below, v2.0 is scheduled to start up to 6 weeks before v1.5 is completed, but only if enough resources are available, and therefore v1.5 still has priority).
The later release
The most frequent, expected cases when items are scheduled in the later release include:
- 固定終了日のリリースのスケジュールが完全に埋められてしまい、一部のエピックまたはストーリーをスケジュールできなかった。これは Later リリースに割り当てられます。
- A release with a dynamic end date is defined (let's say release "2.0"), but no backlog items are assigned to it. In this case, it is assumed that these items are not supposed to be in the scope of "2.0", otherwise they would need to have a fixed assignment to it. As a result, backlog items with release set to "Calculate" will get pushed into the later release.
- No releases are defined at all - in that case everything is scheduled in to the later release as well and you see the projected completion date as the end date of the Later release.
You can check which items fit into a particular release by using the filters.
Additionally, the Releases view provides details on resource utilization, planned and available capacities for the release time frame:
- Resource utilization
- Total effort planned for this release
- Free capacity for this release period
How to scope a fixed release
Use case example: You have a backlog full of epics, stories, fixed target release dates and you want to ship a release every month, even larger updates, three and six months from now.
- Configure your teams and people.
- Configure your releases. For the sake of the example, we'll be scheduling "Phoenix" towards the end of June, and "Mountain Goat" by mid September.
Prioritize and estimate your backlog items.
As soon as you have estimates for your backlog items, Portfolio for JIRA will automatically schedule the items into the fixed end date releases. The scheduling algorithm of Portfolio for JIRA schedules items into the fixed release end date. It considers dependencies and team's availability; depending on these factors, it might happen that a lower priority story still fits into a release, whereas a higher priority one does not.
In the example below, all epics and stories could fit into either version 1.0 or version 1.5. In terms of cycle-time there is no buffer, so the last story/epic really completes with the set release date of 1.5.
If you have a scope for a project and need to figure out how long it takes to complete it, configure your release with a dynamic release date.For example: Let's add one release 'Project Tango' starting on May 1st, with a dynamic end date:
Everything that is not assigned to a release, will automatically be scheduled into the Later release. You can use fixed release assignments to add backlog items to the scope of your project. The forecasted end date is shown in the graphical display.
How to import project release versions
You can import existing versions from your projects and include them in your plans by creating or adding the versions to existing release streams.
- Select your plan and go to Releases.
- Click
. - Select a project. You can exclude existing linked versions.
- In the Import Releases window, choose the stream that your import will be linked to.
- Click Import.
How to link JIRA versions to releases to your plan
You can link existing versions in your JIRA projects to existing releases in your plans. Multiple versions can be linked to a release, but only one version can be added from each project.
- Go to your plan > Releases.
- Select
and mark Version Link if it's not yet checked. - Locate the release you want to add a version to and select the field called Version Link.
- Select a project from the list and a version.
- Click Add.
