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, that'll take you through the fundamentals of Portfolio for JIRA, and get you set up for success!

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

 

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

When you create a Portfolio for JIRA plan, 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 JIRA 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. [管理] > [課題] > [画面] の順に移動します。
  2. フィールドを追加したい画面を編集します。
  3. [親リンク] フィールドを追加します。

注意

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

3. プランの作成

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

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

注意

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

 

To create a plan you first need to select the Portfolio tab in the header of JIRA. Then follow these steps: 

  1. [プランの作成] をクリックします。 
  2. プランの名前を入力します。 
  3. 計画している作業の範囲を選択します。複数のソースを選択して、チームやプロジェクトを横断したプランを作成することができます。課題タイプには 3 つのタイプがあります。Board: そのボードのすべての課題が含まれます。
  4. Project: そのプロジェクトのすべての課題を取り込みます。 
  5. Filter: JQL を使用した、課題のカスタム選択を行えます。

 

 

  1. 次に、作業対象の関連リリースを選択します。これらは課題のソースから修正バージョンをマッピングします。 
  2. 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.) 
  3. 最後に、インポートしたい課題を確認します。エピックとストーリーでビューを切り替えることができます。エピックが選択された場合、そのエピックに関連付けられたすべての課題がインポートされます。特定のエピックまたはストーリーをインポートしたくない場合、それらの横にあるチェックボックスを選択解除します。

 

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

右上に、ユーザーが管理可能な、範囲チーム、およびリリースの 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 週間あたりで費やす平均作業時間を設定します。これは、完了すべき作業のために費やす時間の平均です。チームの稼働時間と同じではありません。

チームのベロシティを設定したら、チーム メンバーを追加できます。ユーザーをチームまたは個人レベルで管理することを選択できます。個人レベルから計画すると、空き状況やスキルに関連する追加の変数を追加できるため、製品のアルゴリズムでより正確なロードマップを計算できます。キャパシティ ビューは開発チーム リードがチームの作業を考慮するための優れた機能ですが、個人レベルから計画することで、それぞれのユーザーのキャパシティをより詳細に検討できます。 

チームのベロシティを設定したら、チーム メンバーを追加できます。ユーザーをチームまたは個人レベルで管理することを選択できます。個人レベルから計画すると、空き状況やスキルに関連する追加の変数を追加できるため、製品のアルゴリズムでより正確なロードマップを計算できます。キャパシティ ビューは開発チーム リードがチームの作業を考慮するための優れた機能ですが、個人レベルから計画することで、それぞれのユーザーのキャパシティをより詳細に検討できます。 

注意

2 つ以上のチームに所属するメンバーがいる場合、そのユーザーを関連するすべてのチームに追加し、各チームでの作業状況を表すように週ごとの作業時間を分散します。なお、チームのベロシティを使用して簡単に計画を作成できるため、チーム メンバーの追加は必須事項ではないことにご注意ください。

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

 

注意

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

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

注意

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

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. 

リリースに固定リリース日がある場合、そのリリースの期間は固定されます。リリースに大量の作業を割り当て、リソースが不足すると、赤色のタイムラインで表示されます。

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

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

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

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

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

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

  1. [リリースを作成] をクリックします。
  2. [プロジェクト横断リリース] を選択します。
  3. リリースに関連するプロジェクトを選択します。 
  4. 開始日終了日を設定します。

5. 最新に保つ

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

With your working plan you can manipulate data and instantly calculate the impact of change. Any changes made to issues in JIRA will automatically update the data in your portfolio plan. But think of Portfolio for JIRA as a sandbox where you can make changes and commit them back to JIRA. 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 JIRA. 

What-if シナリオの計画 

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

6. プランで作業する

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

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

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

依存関係のセットアップ 

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. [管理] > [アドオン] > [Portfolio 依存関係] に移動します。
  2. 含めたいリンク タイプを追加します (ブロック順を右側で確認します)。

プラン設定の使用 

To check out the scheduling options, go to Plan > Configuration. This is where you can tweak how Portfolio for JIRA assigns work.

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

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

  1. [設定] 配下の [Commit of changes] に移動します。
  2. [Commit issue assignee] を有効化します。
  3. チケットをチーム メンバーに割り当てる 

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

  • 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”. 

注意

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

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

異なる見積り手法を使用するプロジェクトがプランにある場合、そのようなユースケースに対応する機能を利用できます。プラン > [設定] > [Issue sources] の順に移動します。プランで別の見積り方法を使用するそれぞれの課題ソースに対して変換率を設定できます。変換率を設定する方法について、見積り方法が混在しているプランの場合、プランは時間ベースの見積りのままにし、次のステップを使用して、ストーリー ポイントを時間に変換することをおすすめします。 

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

  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.

見積り: ストーリー ポイント、時間、または日で測定される、予測される作業量。

チームのベロシティ: 通常の頻度でチームが完了できる作業量または作業時間。

優先度: 範囲テーブルでのアイテムのランクは課題の優先度を反映します。アイテムをドラッグ アンド ドロップして優先度を調整できます。

リリース: リリースへの課題の割り当てと、リリースの開始日および終了日。

スキル: 特定のスキルを必要とする作業アイテムの見積り量。スキルは個々のチーム メンバーに割り当てることができます。

作業ステージ: 並行して発生する可能性があるアクティビティ、または連続アクティビティ。

空き状況: チームとチーム メンバーの空き状況。

依存関係: バックログのアイテム間での、ブロックされているアイテムまたはブロックしているアイテム。

見積りの変換: 混合された見積りを使用して計画している場合の、課題単位のソースの変換率。

構成可能な制約: 例: 1 つのストーリーで並行して作業することができるユーザーの数。

ヒント 

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


 


ユースケース

ビデオチュートリアル

FAQ

最終更新日 2018 年 9 月 28 日

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

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