Getting started with Portfolio for JIRA

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Once you start to understand the fundamentals of long-term agile planning and how these concepts work in Portfolio for JIRA, you can begin to build out your Portfolio for JIRA plan.

To help bring everything together, we outlined below how to set up Portfolio for JIRA with your existing JIRA application instance. This process will follow the best approach for implementing Portfolio for JIRA:

  • Organize your existing JIRA projects.
  • Configure Portfolio for JIRA.
  • Create your plan.

You can also view our webinar, which will take you through the fundamentals of Portfolio for JIRA, and get you set up for success!

1. 課題ソース (プロジェクト、ボード、またはフィルター) の整理


課題ソースを整理する方法をこちらでご確認ください

When you create a plan in Portfolio for JIRA, you need to select the issue sources you want to pull into your plan. Issue sources are projects, boards, or filters that contain the issues you will use to forecast a roadmap for your plan. Since this setup practices a scrum methodology, we recommend using boards, because they provide the most functionality for managing with Portfolio for JIRA.

注意

Do not make Fix Version a ‘hidden’ field as this is a MUST HAVE for Portfolio for JIRA. Also, be careful when setting up ‘required’ custom fields as they can prevent issues from being created inside Portfolio for JIRA. 


イニシアチブなどのカスタム構成を使用する予定の場合、個別のプロジェクトを作成し、そのプロジェクトの課題を個別に保存することをおすすめします。そのプロジェクトで課題タイプを構成し、カスタム階層の課題タイプ用のカスタムの課題タイプがない場合はそれを作成します。カスタム階層を使用しない場合、ステップ 3 にスキップしてかまいません。

階層を使用するかどうかが不明な場合、エピックとストーリーから開始して、あとから再度検討することができます。

2. カスタム階層の構成 (任意)

階層の構成方法をこちらでご確認ください。

Now that you have a project and an issue type for your custom hierarchy set up, you will need to configure Portfolio for JIRA so that it knows what issue type to link to the hierarchy level.

1. [管理] > [アドオン] > [Portfolio 階層の構成] に移動します。

2. Create levels and map them to your JIRA issue types.

注意

You can edit these levels any time and Portfolio for JIRA will reconfigure your roadmap accordingly - nothing is set in stone! 


この機能はストーリー ポイント (または見積り) をサブタスクから最上位のレベルまで集約します。これにより、ユーザーはチームやプロジェクトを横断する大規模な作業を正確に見積もることができるようになります。これらはすべて、便利なロードマップを作成するために必須の要素です。

One of the key components of portfolio management - and indeed any agile process - is visibility; it is essential to have end-to-end traceability from board strategy to team tasks. Portfolio for JIRA has a 1:1 relationship with native JIRA, meaning these issue types can be viewed in the normal issue view with their hierarchical parent and child links.

When you decide on your hierarchy, you need to configure this in the Portfolio for JIRA administration settings. Since this is a global setting it is important to have all the teams using the hierarchy feature in Portfolio for JIRA aligned.

To see this relationship in your JIRA project, just add the parent link field to your screens to expose this link and provide full top-down (and bottom-up) visibility:

  1. Go to Administration > Issues > Screens.
  2. フィールドを追加したい画面を編集します。
  3. [親リンク] フィールドを追加します。

注意

親リンク フィールドは JQL で検索できるため、特定の機能 / イニシアチブの子課題を表示するフィルターをカンバン ボード用に作成できます。ある親課題の子課題の一覧を取得するには “Parent Link” = EX-000 を、複数の親課題リンクから子課題を取得するには “Parent Link” in (EX-000, EX-001, EX-002, EX-003) を入力します。

3. プランの作成

最初のプランを作成する方法をこちらでご確認ください。

課題ソースと階層の準備が整ったら、プランの作成を開始しましょう。

注意

このステップはこれまでのステップと同様、一般に、製品の所有者、またはロードマップの所有者を保有することになる製品マネージャーが行います。 


To create a plan, follow these steps: 

  1. In your JIRA application, go to Portfolio (in header) > Create. The 'Create' page will be displayed.
  2. Select Create a plan, then click Create plan.
  3. プランの名前を入力します。 
  4. Select the scope of work you are planning for. Remember that you can connect to multiple sources to create cross-team, multi-project plans. There are three types of issue sources:
    • Board – all issues on that board are included
    • Project – pulls all issues from that project 
    • Filter – for custom issue selection using JQL

  5. Select the relevant releases you want to work with. These map to the fix versions from your issue sources. 
  6. Then you will be prompted with Teams where you can add teams. By default, Portfolio for JIRA creates a team per issue source. (These can be amended at any time once the plan has been created.) 
  7. 最後に、インポートしたい課題を確認します。エピックとストーリーでビューを切り替えることができます。エピックが選択された場合、そのエピックに関連付けられたすべての課題がインポートされます。特定のエピックまたはストーリーをインポートしたくない場合、それらの横にあるチェックボックスを選択解除します。


この段階で、ロードマップは、課題の優先度、チームのベロシティ、課題の見積り、およびプランのソースに指定した任意の修正バージョンに基づいて作成されます。課題に見積もりがない場合もプランを作成できますが、スケジュール (ビジュアル ロードマップを含む) は、課題やエピックに見積りを設定するまでプランに表示されません。 

右上に、ユーザーが管理可能な、範囲チーム、およびリリースの 3 つの主要な領域が表示されます。レポート セクションを使用すると、情報をよりわかりやすい形式で表示したり、ほかのユーザーと共有したりすることができます。 

4. チームの構成

チームを構成する方法をこちらでご確認ください。

プランを作成したらチームセクションに移動し、ベロシティやキャパシティ メトリックなどのチーム構成が適切にセットアップされていることを確認します。

プランの作成ウィザードで設定されたチーム構成で問題ない場合、このステップをスキップしてステップ 5 に進みます。 

チームのベロシティ

  • For Scrum boards, Portfolio for JIRA can work out your expected sprint velocity based on the average of your past sprints. This can be changed manually at any time to account for team changes (when you are first getting started with Portfolio for JIRA, this does not need to be adjusted). 
  • カンバンの場合、チームが 1 週間あたりで費やす平均作業時間を設定します。これは、完了すべき作業のために費やす時間の平均です。チームの稼働時間と同じではありません。

Once your team velocity is set, you have the option to add team members. You can choose to manage your people at either the team or individual level. Planning from an individual level lets you provide additional variables about availabilities and skills, so our algorithm can calculate a more accurate roadmap.

Additionally, while the Capacity view is a great feature for development team leads to consider how much work is on the team’s plate, planning from an individual level allows you to dig much deeper into each individual’s capacity.

注意

If you have a member who's in more than one team, then add that individual to all relevant teams and distribute their weekly hours to proportion their effort between teams. Also note that adding team members is not necessary since you can easily plan with team velocity.

チーム メンバーを追加するには、[+ ユーザーを追加] をクリックします。チームに加入予定の新規採用者などの変数向けに、アカウントにバーチャル チーム メンバーを作成できます。 


注意

チームを共有チームにし、複数のプランでチームを使用可能で、チーム メンバーのスキルの更新が一度で済むようにします。 

課題画面に [チーム] フィールドを追加すると、割り当てられたチームを課題に表示できます。

注意

チーム フィールドはほかの方法でも使用できます。たとえば、エピック レベルのスクラム / カンバン ボードのクイック フィルターとして使用して、業務を横断するワークロードを簡単に表示できます。

5. リリースの管理

リリースを管理する方法をご確認ください。

Understanding how teams work in Portfolio for JIRA is important to understanding how velocity is calculated for releases. After that is sorted out, the next step is to decide how you want releases to be mapped out and calculated in the roadmap view of the plan. The release settings will dictate how Portfolio for JIRA schedules tasks in sequence and presents your roadmap as either on-track or overbooked. 

If the release has a Fixed Release Date then that release is time-boxed. Overbooking and assigning too much work to a release will result in a red timeline:

プロセスに最適なメソッドを決定することで、予定されている日付に確実に合致する将来のゴールやマイルストーンを計画できます。 

共有リリースで複数のチームがアイテムに取り組むことに不安な場合、プロジェクト横断リリース オプションを使用できます。このプランはそれぞれのプロジェクトに個々のリリースを含み、それらの同期を維持します。これにより、管理負荷を軽減し、計画を簡単に行えます。

リリースに動的なリリース日がある場合、そのリリースの範囲は固定されます。このリリースでリソースが不足することはありません。リリースに割り当てられた範囲とリソースに従い、タイムラインが更新されます。 

プロセスに最適なメソッドを決定することで、予定されている日付に確実に合致する将来のゴールやマイルストーンを計画できます。 

共有リリースで複数のチームがアイテムに取り組むことに不安な場合、プロジェクト横断リリース オプションを使用できます。このプランはそれぞれのプロジェクトに個々のリリースを含み、それらの同期を維持します。これにより、管理負荷を軽減し、計画を簡単に行えます。

プロジェクト横断リリースを作成したい場合、次の手順を実行します。 

  1. Click Create Release.
  2. Select Multi Project.
  3. Select relevant projects for the release.
  4. Set Start and End dates.

6. 最新に保つ

プランを最新に保つ方法をご確認ください。

With your working plan, you can manipulate data and instantly calculate the impact of change. Any changes made to issues in your JIRA application will automatically update the data in your plan. But think of Portfolio for JIRA as a sandbox where you can make changes and commit them back to your JIRA application. If you are not happy with those changes, you can always revert.

Whenever you make a change like move an epic into a different release, an orange indicator will flag the change and the number count of your uncommitted changes – seen in the upper left-hand corner of the plan – will increase. Click on the uncommitted changes to open the commit/ revert dialog and once you are satisfied with all of your changes you can commit those changes into your JIRA application.

What-if シナリオの計画 

コミット / 元に戻す機能を使用することで複数のシナリオを試し、最適なものを採用できます。たとえば、リリース範囲の変更やチーム メンバーの追加によるリリース日への影響を確認したい場合、変更をサンドボックスで試して、複数の変数を使用してプランを計算できます。 

7. プランで作業する

プランで作業する方法をご確認ください。

プランの準備が整いました。スケジュール ビュー (画面の上半分) は、プランの作成時に提供された範囲、リリース、およびチーム情報に基づいて計算されています。 

この段階では、基本となるプランを利用して、データを仮変更し、ロードマップを確認できます。しかしながら、ほかにも、さまざまなユースケースに対応できる多数の高度な機能があります。このセクションでは、スケジュール ビューでのさまざまなフィルター オプションなどの、いくつかの便利な機能について説明します。特定のリリースを分離したり、チームごとの分割ビューを表示して、計画時に注意が必要な箇所を確認したりすることができます。 

依存関係のセットアップ 

Dependencies can be created and visualised in Portfolio for JIRA using issue links. By default, only ‘Blocks’ and ‘Blocked by’ issue links control dependencies. You can add more issue link types for Portfolio for JIRA to consider dependencies through the Admin. 

  1. Navigate to Administration > Add-ons > Portfolio Dependencies.
  2. 含めたいリンク タイプを追加します (ブロック順を右側で確認します)。

プラン設定の使用 

The scheduling options can be found in the Plan configuration page. This is where you can tweak how Portfolio for JIRA assigns work.

To configure your plan:

  1. Go to your plan via Portfolio (in header) > View Portfolio > click your plan.
  2. Click more () next to the plan name > Configure.

主に次の点を考慮します。 

Issue Assignee Import Level – To set the JIRA ticket assignee to the team member assigned in your plan:

  1. Go to Commit of changes section under Configuration.
  2. Enable Commit issue assignee.
  3. Assign the ticket to your team member.

チケットの担当者は、それらのユーザーに割り当てられた課題でのみ設定されます。 

  • Dependent Story Constraint – If issues have dependencies, Portfolio for JIRA will schedule them in different sprints (or on different days for Kanban) unless you say otherwise. 
  • Enforce Concurrent Work – 1 つのアイテムに複数のチーム メンバーが割り当てられている場合に、スケジューリング アルゴリズムでそのアイテムのすべての作業が 1 つのスプリントにスケジューリングするようにします。これを行わない場合、個々のチーム メンバーの作業はキャパシティに余裕があるタイミングに割り当てられ、1 つの作業アイテムが複数のスプリントにまたがる可能性があります。

スプリントでの計画 

If you are working with sprints, you can use a board as an issue source. Sprints that you create in your board backlog are dynamically connected with Portfolio for JIRA and will be used to manage sprint assignments. You cannot create custom sprints from inside Portfolio for JIRA, so make sure you create your upcoming sprints from inside JIRA. 

The rank of backlog sprints determines the order in which they will be scheduled. Sprint names, dates, and sprint assignment of issues are all surfaced in Portfolio for JIRA. 


In Portfolio for JIRA, sprints start by default from the date you calculated the schedule. If your sprints start on a particular date then Portfolio for JIRA will schedule your sprint from your specified date and all future sprint cadences will be projected immediately following your active sprint.

From Portfolio for JIRA, there are two ways to assign issues to a sprint depending on your usage. 

Statically assign sprint – 課題をスプリントに割り当てる直接的な方法として、スプリント列を使用できます。そのスプリントに関連付けられているチームが、静的に、または計算の結果として、最初に課題に割り当てられる必要があります。その後、範囲テーブルのスプリント列を使用してスプリントを選択できます。 

Assign calculated sprint – Alternatively, you can bulk-assign one or multiple issues calculated to a sprint. When you calculate a schedule and you want the forecasted sprints to be reflected on the JIRA board, simply click on the sprint name and select “assign X calculated issues and commit changes”. 

注意

これは、複数のスプリントを横断する課題や、ストーリーレベルのビューで開示されている見積り済みのエピックには影響しません。

複数の見積り方法を持つプラン 

If you have projects in your plan that follow different estimation methods, there is a functionality to accommodate such a use case.

  1. Go to your plan via Portfolio (in header) > View Portfolio > click your plan.
  2. Click more () next to the plan name > Configure > Issue sources.

After that, you can set a conversion ratio for each issue source that uses a different estimation method from your plan. But how do you set a ratio? For a mixed estimate plan we recommend you keep your plan in time-based estimation and follow these steps to set your story-point to hours conversion ratio: 

ストーリー ポイントから時間への変換 

  1. チームでの 1 週間あたりの合計キャパシティを決定します (例: 1 週間あたり 40 時間のキャパシティを持つメンバーを 5 人含む場合、200 時間のチーム キャパシティ)。 
  2. チームの 1 週間のスプリント ベロシティを、1 週間のキャパシティで割ります (例: 1 週間のベロシティが 30 の場合、200/30 = 6.667)。 
  3. この結果を変換率として使用します。 

変換率はこの値から変更する場合もあります。チームでの作業を行うにつれて、チームのパフォーマンスをより良く表すように変換率を更新できます。時間をストーリー ポイントに変換することもできますが、使用できる最適なベロシティ (およびそこから導き出される変換率) の算出は困難な場合があります。

プランのレポート 

レポート タブをクリックし、テーマ、リリース、スケジュール、キャパシティ、スプリント、および範囲の 6 つの異なるレポートとしてデータを可視化および共有できます。 

レポートは、このような専用のビューを使用してデータを詳細に分析し、データの永続的なビューを共有するのに便利です。たとえば、iOS チームのみの特定の日付範囲のロードマップをマネージャーに共有したいとします。プランをフィルタリングして関連するデータを表示し、URL または埋め込み可能な iFrame を生成して共有できます。 

ロードマップのアイテムと組織レベルの領域との関連性をレポートで示したい場合、テーマを使用できます。これは、戦略的な目標に対する作業状況を追跡します。目標となる作業と、実際に完了する作業との比較を、リアルタイムで確認できます。 

One advantage of using themes is that you can visualize your schedule with each item color-coded by theme:


外部の状況への対応 

While all of this is great in theory, many teams have dependencies and factors that affect their roadmap that are external from JIRA. It may be other planning tools, third-party vendors, or simply a part of the business that is not ready to change. 

If you have a dependency or external milestone that you need to reflect in your plan, try using the earliest start date function. This will pin that task into the timeline, and the scheduling algorithm of Portfolio for JIRA will work around it.

How does Portfolio for JIRA calculate your schedule?

Portfolio for Jira のスケジューリング アルゴリズムは、提供されたデータを使用して、現実的なデータ駆動のロードマップを作成します。ロードマップの作成は、見積りとチーム ベロシティのみを使用して簡単に行うこともできますが、変数を提供することでよりきめ細かな制御を行うことができます。

So that you do not get lost in the details, here is a list of all the variables our algorithm considers and what they mean. Do not stress if you do not use all or even most of them. The level of detail you provide Portfolio for JIRA depends on your team.

Some concepts in Portfolio for JIRA:

  • Estimate: The expected work effort measured in story points, hours, or days
  • Team velocity: How much work effort or how many hours a team can complete in a regular cadence
  • Priority: The rank of items in the scope table reflect the issue’s priority. Drag and drop items to re-prioritize them
  • Release: Assignment of issues to releases and the start and end dates of releases
  • Skills: Amount of a work item’s estimate that requires a particular skill. Skills can be associated with individual team members
  • Work stages: Activities that can happen either in parallel or sequential activities
  • Availability: Teams and team member availability
  • Dependencies: Blocked or blocking items between backlog items
  • Estimate conversion: A per-issue-source conversion rate when planning with mixed estimates
  • Configurable constraints: For example, how many people can work in parallel on a story

ヒント 

  • 何が必要かを見極める – 最初はプランの構成方法の検討に時間を割き、あとから成果を得ます。
  • 計画と再計画 – 状況は変わります。プランも変える必要があります。
  • 遠い将来の心配をしすぎない – まずは来週から開始し、先のことはそれから考えましょう。
  • コミュニケーション – プランは全員に影響します。十分に情報を共有しましょう。 
  • 何より、アジャイルであること: 計画を開始し、結果を確認して改善を進めていきましょう。




ユースケース

ビデオチュートリアル

FAQ

最終更新日 2018 年 9 月 28 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.