fbpx

PI Planningとは?

アジャイルをスケールし、SAFeフレームワークを導入する組織にとって、スムーズで摩擦のないPI Planningプロセスを実現することが最大の課題であることは言うまでもありません。業種や企業規模を問わず、PI Planningを成功させることで、透明性が高く行動志向のアラインメント文化を根づかせることができます。まさにSAFeの礎となるイベントです。

PI Planningはどのように実施するのか?

「PI Planningの実施方法」が課題であれば、この包括的なPI Planningガイドで、その問いに含まれるすべての疑問への答えが見つかります。
続く5つのセクションでは、次の問いを詳しく解説します:

  • PI Planningを成功させるとはどういうことか?
  • 優れたバーチャル/分散/リモートPI Planningをどう実施するか?
  • PI Planningの課題をどう克服するか?
  • PI Planningの準備チェックリストとは?
  • PI Planningのテンプレートはありますか?

最後に、PI Planningにそのまま使える、編集・ダウンロード可能なステップバイステップガイド をご紹介します。

PI Planning 101 PI Planningを成功させるとはどういうことか?

Program Increment(PI)Planningは、共通のビジョンで結ばれたAgile Release Trainのチームが一堂に会し、新しいフィーチャーを計画し、依存関係とリスクを議論し、今後の進め方を描き出すタイムボックス化されたイベントです。これなしにSAFeを実装することはできません。

実際、SAFeの考え方に立てば、PI Planningはスケールドアジャイルフレームワークにおける唯一無二の要となる要素です。

プロジェクトが複数のクロスファンクショナルチームに広がると、ナレッジの基盤が損なわれがちです。その結果、質の低い意思決定、バリューチェーンの弱体化、キャパシティと負荷の不一致といったコストが組織にのしかかります。
PI Planningは、全体を見渡せる可視性、徹底したアラインメント、そして共通ビジョンへの明確なコミットメントによって、この課題に対処します。

PI Planningの目標を正しく理解できれば、課題の半分は解決したも同然です。

SAFeの解釈を借りるなら、
PI Planningは、すべてのARTにとって不可欠な、ケイデンスに基づく同期ポイントです。

ここから何が読み取れるでしょうか。
PI Planningの成功が、Agile Release Train(ART)のチームにもたらすものは次のとおりです。

  • 同期、
  • (チーム間およびART間の)コラボレーション、
  • アラインメント(ビジネスコンテキストのワークフロー、目標、ビジョンなど)、
  • 人的ネットワーク、
  • システムアーキテクチャの評価、
  • 過剰な仕掛り作業(WIP)の排除、
  • 意思決定の効率化、
  • 予測可能性とアジリティを支える透明性。

成功したPI Planningイベントは、これらすべてを満たしたうえで、イテレーションの最後に「動くソフトウェア」を示すことができます。

端的に言えば、次の2つのアウトプットを生み出せていれば、PI Planningイベントは目標を達成したと言えます。

  • コミットされたPI Objectives
  • PI Objectivesとは、ARTを構成する各チームが作成したSMARTな目標の集合で、Business Ownersがビジネス価値を割り当てます。PI Objectivesへのコミットメントは、ARTにとって最も重要な到達点です。
  • Program Board
  • ARTの状況を最も正確に映し出すデータの集約で、新しいフィーチャーのデリバリー日、チーム間のフィーチャー依存関係、関連するマイルストーンを可視化します。ARTにとっての水晶玉とも言える存在です。

Program Board

KendisのPI Planningボードの例(画像をクリックしてオンラインで編集

SAFeのPI Planningにおいて、Release Train Engineerの役割は非常に重要です。RTEはPI Planningセッションの推進役であり、サーバントリーダーでもあります。全体の枠組みを保ちながらセッションを運営し、参加者間のコラボレーションとアラインメントを確かなものにする責任を担います。アジャイルチームにおけるScrum Masterと同じ役割を、ARTにおいて果たすのがRTEです。

PI Planning参加者の役割をまとめると、次のとおりです。

役割
担う機能

ユーザー
ソリューションのユーザー中心性を評価する

ステークホルダー
各参加ユニットの成功度合いを評価する

アジャイルチーム
  • チームブレイクアウトでユーザーストーリーをタスクに分解する
  • イテレーション計画とチームのPI Objectivesを作成する
  • リスクを特定し対処する
  • Confidence Voteを行う

システムアーキテクト/エンジニアリング
  • ARTのアーキテクチャビジョンを提示する
  • チーム間の依存関係とリスクの整理を支援する

システムチーム
統合とテストのバックログ項目を定義する

Business Owners
ビジネス価値を付与し、チームのPI Objectivesを承認する

Scrum Masters
  • ARTの活動、システムデモ、Inspect and Adaptに向けたチームの準備を支援する
  • 正規化された見積りの確立をチームに導く
  • フィーチャーとケイパビリティの見積り方法の理解を助ける

Product Owners
  • バックログの優先順位付けを行う
  • ソリューションで提供予定のフィーチャーを示すビジョンを提示する
  • 関連する今後のマイルストーンを共有する
  • フィーチャーをユーザーストーリーに分解する

Release Train Engineer
  • プランニングのプロセスと期待される成果を提示する
  • マネジメントレビュー、問題解決セッション、レトロスペクティブをファシリテートする。そのため、PI Planningセッションの実施はRTEの責任となる

Program Incrementの期間はおよそ8〜12週間です。
この範囲を踏まえ、PI Planningは四半期ごとに実施され、一般的なスケジュールは次のとおりです。

  • 第1四半期のPI Planning:12月
  • 第2四半期のPI Planning:3月
  • 第3四半期のPI Planning:6月
  • 第4四半期のPI Planning:9月

これらは定期的かつ固定されたスケジュールに沿って、前もって計画されます。招待も早めに送付し、準備が滞りなく整うようにします。

対面のProgram Increment Planningは通常2日間にわたり、あらかじめ決められたアジェンダと、個別にスケジュールされたイベントで構成されます。アジェンダは次のとおりです。

タイムゾーン AEST
1日目のアジェンダ
8:00 – 9:00 am
ビジネスコンテキスト 1時間

9:00 – 10:30 am
プロダクト/ソリューションビジョン 1時間30分

10:30 – 11:30 am
アーキテクチャビジョン & 開発プラクティス 1時間

11:30 – 1:00 pm
プランニングコンテキスト & ランチ 1時間30分

1:00 – 4:00 pm
チームブレイクアウト 3時間

4:00 – 5:00 pm
ドラフトプランレビュー 1時間

5:00 – 6:00 pm
マネジメントレビュー & 問題解決 1時間

タイムゾーン AEST
2日目のアジェンダ
8:00 – 9:00 am
プランニング調整 1時間

9:00 – 11:00 am
チームブレイクアウト 2時間

11:00 – 1:00 pm
最終プランレビュー & ランチ 2時間

1:00 – 2:00 pm
プログラムリスク 1時間

2:00 – 2:15 pm
Confidence Vote 15分

2:15 – 4:00 pm
プランの修正(必要な場合) 1時間45分

4:00 – 6:00 pm
プランニングレトロスペクティブ & 次への一歩 2時間

丸2日間にわたる、一般的な対面PI Planningイベントのスケジュール例です。



分散型やリモートのPI Planningでもアジェンダは変わりませんが、イベントのスケジュールは多くの要因に左右されます。それらは次のセクションで解説します。

ボーナスTIP I

ボーナスTIP I

対面のPI Planningでは、休憩が少なく、人との対話や喧騒に満ちた濃密な2日間になります。一方、バーチャル環境では、体験全体を画面向けに設計し、参加者の集中をいかに保つかに重点を置く必要があります。画面疲れを避けるため、1日あたりの拘束時間を短くして3〜4日間に分けて開催するのが効果的です。

分散PI Planning 優れた分散/リモートPI Planningをどう実施するか?

アジャイルマニフェストは、次のように明確に述べています。

  • 情報を伝える最も効率的で効果的な方法は、開発チームの内部および開発チームへの対面での会話である。

一般的な認識とは異なり、PI Planningの本質的な強みは、チームが同じ場所に集まることにあるわけではありません。物理的な距離の有無が、スムーズで透明性の高いコミュニケーションの妨げにならないところまで、推進の仕組みを設計し強化することにこそ本質があります。

PI Planningがこれまで対面イベントとしてのみ実施されてきたのは事実です。しかし、長期的にこの形を維持しにくくする要因がいくつもあります。

  • 複数拠点・多文化のチームを対象とした運営ロジスティクスの負担、
  • パンデミックを踏まえた地域ごとの渡航制限
  • 慣れない環境で心理的安全性を確保することの難しさ
  • イベントに十分な広さと適切さを備えた会場の確保、
  • そして忘れてはならない、これら大がかりな手配にかかる費用と時間のコスト。

もちろん、バーチャルなPI Planningの実施も簡単ではありません。しかし、アジャイルチームが仕事の面でも人としても認められていると感じられる場を丁寧に設計できれば、リモートイベントのROIは対面を上回ることさえあります。

本ガイドの各セクションとボーナスTIPで紹介する経験知と実践的なノウハウを、ぜひ持ち帰ってください。

リモートPI Planningを企画する際に、必ず検討すべき重点領域があります。

  • プランニング拠点:必要な拠点数を見極め、分散する拠点をできるだけ少なくします。
  • PI Planningアジェンダ:参加チームの複数のタイムゾーンに配慮した、包括的なアジェンダを作成します。
  • 設備:プランニングを実施するのに適した物理スペースを用意します。
  • ワーキングアグリーメント:参加者のニーズに応え、ARTの一人ひとりにとって最適な体験にします。
  • ツール:幅広いプランニング活動を支える適切なテクノロジーを導入します。
  • ファシリテーション:分散PI Planningを成功に導きます。

正直なところ、これは組織ごと(そしてタイムゾーンごと)に異なりますが、疲労を最小限に抑えたリモートPI Planningのスケジュールを考えるうえで、次の例が参考になるはずです。

ゾーン1 AEST
ゾーン2 CET
1日目のアジェンダ
3:00 – 3:20 pm
7:00 – 7:20 am
オープニング この後10分間の休憩 20分

3:30 – 3:50 pm
7:30 – 7:50 am
ビジネスコンテキスト この後10分間の休憩 20分

4:00 – 4:20 pm
8:00 – 8:20 am
プロダクト/ソリューションビジョン この後10分間の休憩 20分

4:30 – 4:50 pm
8:30 – 8:50 am
アーキテクチャビジョン この後10分間の休憩 20分

5:00 – 5:20 pm
9:00 – 9:20 am
開発プラクティス この後10分間の休憩 20分

5:30 – 5:50 pm
9:30 – 9:50 am
プランニング要件 この後50分間の食事休憩 20分

6:40 – 8:30 pm
10:40 – 12:30 pm
チームブレイクアウト Scrum of Scrumチェックポイント 1時間50分

ゾーン1 AEST
ゾーン2 CET
2日目のアジェンダ
3:00 – 3:20 pm
7:00 – 7:20 am
チームブレイクアウト(必要な場合) この後10分間の休憩 20分

3:30 – 3:50 pm
7:30 – 7:50 am
チーム同期 この後10分間の休憩 20分

4:00 – 4:20 pm
8:00 – 8:20 am
ドラフトプランレビュー この後10分間の休憩 20分

4:30 – 4:50 pm
8:30 – 8:50 am
マネジメントレビュー & 問題解決 (+10分間の休憩) 20分

5:00 – 5:20 pm
9:00 – 9:20 am
プランニング調整 この後10分間の休憩 20分

5:30 – 5:50 pm
9:30 – 9:50 am
プランニング要件 この後50分間の食事休憩 20分

6:40 – 8:30 pm
10:40 – 12:30 pm
チームブレイクアウト Scrum of Scrumチェックポイント 1時間50分

ゾーン1 AEST
ゾーン2 CET
3日目のアジェンダ
3:00 – 3:20 pm
7:00 – 7:20 am
チームブレイクアウト(必要な場合) この後10分間の休憩 20分

3:30 – 3:50 pm
7:30 – 7:50 am
チーム同期 この後10分間の休憩 20分

4:00 – 4:20 pm
8:00 – 8:20 am
最終プランレビュー この後10分間の休憩 20分

4:30 – 4:50 pm
8:30 – 8:50 am
マネジメントレビュー & 問題解決 (+10分間の休憩) 20分

5:00 – 5:20 pm
9:00 – 9:20 am
プランニング調整 この後10分間の休憩 20分

5:30 – 5:50 pm
9:30 – 9:50 am
プランニング要件 この後50分間の食事休憩 20分

6:40 – 8:30 pm
10:40 – 12:30 pm
チームブレイクアウト Scrum of Scrumチェックポイント 1時間50分

2つのタイムゾーンを対象に、こまめな休憩を挟みながら3つの半日に分けた、リモートPI Planningのスケジュール例です。

ボーナスTIP II

ボーナスTIP II

分散型やリモートのPI Planningでは、各拠点のチームのタイムゾーンを常に考慮してください。PI Planningの成否は、目標の明確さ、方向性のアラインメント、チームの透明性、そしてセッションの時間設定と構成を、どれだけ質の高い体験として設計できるかにかかっています。非同期の活動には十分な時間の余裕を持たせ、同期での活動は時間帯に配慮して設定しましょう。予定が押した場合に備え、追加の1日を確保しておくことをおすすめします。

PI Planning:課題 PI Planningの課題をどう克服するか?

Program Increment Planningに参加するチームが直面する戦略的な課題のうち、主なものは次のとおりです。

  • ART全体の透明性とアラインメント、
  • 効果的なコラボレーション、
  • 効率的でインパクトのある意思決定、
  • 意味のあるコミュニケーション、
  • 目的意識のあるエンゲージメント。

実行面では、これらの課題は次のような形で現れます。

  • データの統合不足、
  • 時間がかかり誤りも生じやすい手作業での情報収集、
  • ビジネス目標を見失うこと、
  • 適切でない時間帯のセッション、
  • 長時間で負担の大きいセッション、
  • 技術的なトラブル、
  • 準備不足のセッション運営。

Jiraを使うチームを抱えるRTEにとって、対面・リモートを問わずPI Planningを実施する際の最大の課題は、プランニングボードとJiraの間でスムーズかつ手間のかからないリアルタイム双方向連携を実現することです。

プランニングボードに可視化ツールを使う組織もあります。一見するとPI Planningを手軽に実施できる方法に見えますが、イベント中やイベント後に深刻な問題を招きかねません。
よくあるつまずきは次のとおりです。

  • Jiraのパフォーマンス

    PI Planning中に、多数のカードが連携した可視化ボードへ大勢が同時にアクセスすると、Jiraのパフォーマンスが著しく低下する事例がSAFeコミュニティで報告されています。

  • 編集権限の制限

    可視化ツールはもともとPI Planningのために設計されていないため、いくつかの制約があります。その1つが、ボードを編集できるユーザー数の上限です。

  • データの手作業での移行

    ALMツールとの間でデータをバックアップし、手作業で移す必要があり、時間と正確性の両面でコストが生じます。

アジャイルをスケールするうえで、これらの課題には大きな代償が伴います。失われる時間や金銭的コストは、その中で測定できる一部にすぎません。メンバーの落胆やモチベーション低下、ARTのチーム間で生じる信頼の欠如は見過ごされがちで、多くの場合は取り返しがつきません。幸い、Kendisを使えば、これらの課題は難なく解消できます。

ボーナスTIP III

ボーナスTIP III

起こり得る問題を把握するため、ファシリテーションのリハーサルを行いましょう。運営を担うチームが、PI Planningを滞りなく進められる状態になっていることが重要です。イベントの運営、人への対応、よくある懸念への回答、そしてこの規模のイベントに伴うプレッシャーへの対処には、彼らの経験が欠かせません。

PI Planning:準備チェックリスト PI Planningの準備チェックリストとは?

PI Planningを成功させるために必要な準備について、助言してくれる人はいくらでもいます。肝心なのは、アジャイルをスケールする組織にふさわしく、準備のプロセス全体を体系的なまとまりに整理することです。

SAFeのガイダンスによれば、PI Planningの準備で検討すべき主要領域は3つあります。

  • 組織面の準備:戦略のアラインメント、チームとトレインの編成
  • コンテンツ面の準備:マネジメントと開発の準備状況
  • ロジスティクス面の準備:イベントを成功させるための考慮事項

この3つのテーマをもとに、特に押さえておきたい確認事項をまとめました。

  • プランニングのスコープとコンテキスト:プランニングの対象範囲(プロダクト、システム、技術領域)は特定できていますか。どのチームが一緒に計画すべきか把握できていますか。
  • ビジネスのアラインメント:Business Ownersの間で、優先順位に関する共通理解はできていますか。
  • アジャイルチーム:すべてのアジャイルチームに専任メンバーがいて、各チームのScrum MasterとProduct Ownerが決まっていますか。
  • エグゼクティブブリーフィング:参加者全員に、現在のビジネスコンテキストを共有するブリーフィング
  • プロダクトビジョンのブリーフィング:プロダクトマネジメントが、Program Backlog上位10件のフィーチャーについて説明しますか。
  • アーキテクチャビジョンのブリーフィング:CTO/エンタープライズアーキテクト/システムアーキテクトが、新しいEnabler、フィーチャー、非機能要件(NFR)について説明しましたか。
  • 拠点:プランニング拠点はいくつ必要ですか。
  • テクノロジーとツール:ALMツールと連携したKendisが、リアルタイムのPI Program Board、PI Objectives、リスクのROAM、依存関係管理、そしてScrum of Scrums、Confidence Vote、Inspect and Adaptといった各種セレモニーをカバーします。分散プランニングやリモート参加者を支えるために、他にどんなツールが必要でしょうか。(ヒント:必要ありません。これで準備万端です。)
  • コミュニケーションチャネル:質の高い体験を実現するための、音声・映像・プレゼンテーション・会話のメインおよび予備チャネル。

このチェックリストが、ARTの参加者全員の貢献に大きく依存していることにお気づきでしょう。前述のPI Planning参加者と役割のセクションにも、それが表れています。

ボーナスTIP IV

ボーナスTIP IV

事前に用意しておきましょう。チームリーダーに連絡が取れる連絡先一覧の資料、コミュニケーションチャネルとその使い分けをまとめたリスト、そしてツールが期待どおりに機能しなかった場合のコンティンジェンシープラン(プランB)です。

PI Planning:ステップバイステップガイド PI Planningのテンプレートはありますか?

ALMツールとしてJiraを使っていても、Azure DevOps/TFSを使っていても、Kendisなら、市場の他のどのソリューションにもできない完成度でPI Planningを実施できます。ぜひお試しください。

PI Planningの準備をより万全にしていただくため、ボードのセットアップ、ユーザーの招待、そして当日までに必要な重要ステップの完了を確認できる、ステップバイステップガイドをご用意しました。

このガイドを読めば、あなたとチームがどこにいても、KendisがPI Planningをどのように支援するのかを一望できます。

KendisがPI Planning向けに提供する強力なデジタルボードは、Jiraボードとの最適化された双方向リアルタイム同期を採用しています。Kendis Program Board上でアイテムを変更するとJiraへ即座に反映され、その逆も同様なので、Jiraとの間でデータを手作業で移す必要はありません。

Jiraユーザー

PI Planning前

  • 01 RTEがKendisでPIボードをセットアップし、PIの日程と期間を設定します
  • 02 Jiraボードと接続します
  • 03 色分けしたチームを作成します
  • 04 Program Incrementのスプリントを定義します
  • 05 JiraフィルターやJQLを使い、Jiraのパフォーマンスに影響を与えずに、フィーチャーをKendisボードへ取り込みます
  • 06 フィーチャーにひも付いたJira上のチームストーリーは、自動的にボードへ取得されます
  • 07 Kendisのチームを、それぞれのJiraボードにマッピングします
  • 08 続いて、チームをKendisボードに招待します
  • 09 ビジネス価値によってビジネスコンテキストを定義し、フィーチャーの優先順位付けを行って、プランニングの準備を始めます。

PI Planning当日

  • 01 チームブレイクアウトでは、Scrum MasterがKendisの各チームエリアで、スプリントごとのチームキャパシティを設定します
  • 02 Jiraボードで優先順位付けしたProgram Backlogから、Kendisボードのスプリントへフィーチャーを引き込みます
  • 03 フィーチャーカードを展開し、タイトルとストーリーポイントの見積りを入力してストーリーを作成します。作成したストーリーは、該当フィーチャーにひも付き、スプリントに割り当てられた状態でJiraにも即座に表示されます
  • 04 ドラッグ&ドロップで依存関係を色分けして可視化し、ステータス、リンク種別、説明を設定します。ボード上の表示の変化から、依存関係の解消状況を追跡できます
  • 05 各目標のビジネス価値を活用し、それぞれをフィーチャーにひも付けます
  • 06 PI内の各目標の進捗を測定します
  • 07 プランレビューでは、Product OwnerがKendisボードを使って依存関係の状況を共有し、リスクを示しながらプランを説明します
  • 08 チームごとのフィーチャー完了予定日を確認します
  • 09 各チームのスプリントにおける、キャパシティと負荷の関係を評価します
  • 10 Kendisボードのリスクレジスターで、リスクをROAMします
  • 11 KendisボードのConfidence Vote機能を使い、PI単位、チーム単位、またはその両方で投票を行います
  • 12 KendisボードのInspect & Adaptモジュールで、Inspect and Adaptセッションを実施します。プログラムのパフォーマンスを測定し、デリバリーを評価します
  • 13 プランニングが完了したら、Kendisボードの状態をトラッキングに切り替えます
  • 14 Kendisボードのデータを、Excelやcsvなど共有しやすい形式にエクスポートします。

PI Planning後

  • 01 Kendisボードの強力なビジュアルマネジメント機能で、依存関係と目標の進捗を追跡します
  • 02 スコープ変更トラッカーで、PIの進捗を自動的に追跡します
  • 03 追加・編集されたフィーチャーや、スプリントが変更されたストーリーを把握してスコープの増加を予測し、当初のPI Planningと比べて実行段階でいつどのようにズレが生じたのかを理解します。

Kendisは、クラウド版ではAzure DevOps、旧セルフホスト版ではTFSとの、シームレスなリアルタイム双方向同期に対応しています。Kendis Program Boardの本質的な強みは、PI Planningのプロセス全体を淀みなくスムーズに進められる点にあります。

Azure DevOps

PI Planning前

  • 01 RTEがKendisでPIボードをセットアップし、PIの日程と期間を設定します
  • 02 該当するURLとAPIトークンを入力して、Azure DevOpsまたはTFSと接続します
  • 03 色分けしたチームを作成します
  • 04 Program Incrementのスプリントを定義します
  • 05 既存のクエリを使うか新しいWiqlを記述して、フィーチャーをKendisボードへ取り込みます
  • 06 ストーリーとフィーチャーの関連付け方を決めます
  • 07 クエリで取得したフィーチャーの子アイテムであるストーリーは、すべて自動的にKendisボードへ取得されます
  • 08 Kendisのチームを、Azure DevOpsにマッピングします
  • 09 続いて、チームをKendisボードに招待します
  • 10 ビジネス価値によってビジネスコンテキストを定義し、フィーチャーの優先順位付けを行って、プランニングの準備を始めます

PI Planning当日

  • 01 チームブレイクアウトでは、Scrum MasterがKendisの各チームエリアで、スプリントごとのチームキャパシティを設定します
  • 02 Azure DevOpsで優先順位付けしたProgram Backlogから、Kendisボードのスプリントへフィーチャーを引き込みます
  • 03 フィーチャーカードを展開し、タイトルとストーリーポイントの見積りを入力してストーリーを作成します。作成したストーリーは、該当フィーチャーにひも付き、スプリントに割り当てられた状態でAzure DevOpsにも即座に表示されます
  • 04 ドラッグ&ドロップで依存関係を色分けして可視化し、ステータス、リンク種別、説明を設定します。ボード上の表示の変化から、依存関係の解消状況を追跡できます
  • 05 各目標のビジネス価値を活用し、それぞれをフィーチャーにひも付けます
  • 06 PI内の各目標の進捗を測定します
  • 07 プランレビューでは、Product OwnerがKendisボードを使って依存関係の状況を共有し、リスクを示しながらプランを説明します
  • 08 チームごとのフィーチャー完了予定日を確認します
  • 09 各チームのスプリントにおける、キャパシティと負荷の関係を評価します
  • 10 Kendisボードのリスクレジスターで、リスクをROAMします
  • 11 KendisボードのConfidence Vote機能を使い、PI単位、チーム単位、またはその両方で投票を行います
  • 12 KendisボードのInspect & Adaptモジュールで、Inspect and Adaptセッションを実施します。プログラムのパフォーマンスを測定し、デリバリーを評価します
  • 13 プランニングが完了したら、Kendisボードの状態をトラッキングに切り替えます
  • 14 Kendisボードのデータを、Excelやcsvなど共有しやすい形式にエクスポートします

PI Planning後

  • 01 Kendisボードの強力なビジュアルマネジメント機能で、依存関係と目標の進捗を追跡します
  • 02 スコープ変更トラッカーで、PIの進捗を自動的に追跡します
  • 03 追加・編集されたフィーチャーや、スプリントが変更されたストーリーを把握してスコープの増加を予測し、当初のPI Planningと比べて実行段階でいつどのようにズレが生じたのかを理解します

Program BoardProgram Board

PI Planningに関する疑問は解消できましたか?

もっと詳しく知りたいことはありますか?
ぜひご知見やご意見をお寄せください。 私たちは改善を大切にしています。🙂

PI Planningに関するよくある質問
SAFeにおけるPI Planningとは何ですか?
PI Planning(Program Increment Planning)は、Scaled Agile Framework(SAFe)におけるケイデンスベースのイベントで、対面でもリモートでも実施されます。Agile Release Train(ART)のすべてのチームが集まり、共通のミッションとビジョンについて足並みをそろえ、今後8〜12週間の作業を計画し、依存関係とリスクを特定して、PI Objectivesにコミットします。SAFeの鼓動とも言える存在で、省略することはできません。
PI Planningはどのくらいの頻度で実施しますか? +
PI Planningは、通常8〜12週間続くProgram Incrementごとに1回実施します。つまり多くの組織では四半期に一度、年4回のペースで、あらかじめ公開された固定のケイデンスに沿って開催し、チームやステークホルダーが予定を立てやすいようにしています。
PI Planningイベントの所要時間はどのくらいですか? +
標準的な対面のPI Planningは、丸2日間連続で行います。分散型やリモートの場合は、アジェンダと成果は同じまま、画面疲れを抑え、複数のタイムゾーンに配慮するために、3〜4回の半日に分けて実施するのが一般的です。
PI Planningは誰がファシリテートしますか? +
PI Planningのファシリテーションは、Release Train Engineer(RTE)が担います。RTEはアジェンダに責任を持ち、進行を管理し、マネジメントレビューと問題解決セッションを取り仕切り、ART上のすべてのアジャイルチームがイベント終了までにコミットされたPI Objectivesを作成できるようにします。
PI PlanningにおけるProgram Boardとは何ですか? +
Program Boardは、PI Planningの中で作成される可視化された成果物です。これから始まるProgram Incrementのスプリントに沿って、フィーチャー、マイルストーン、チーム間の依存関係を配置し、デリバリーのコミットメントとリスクを、ARTが1つの共通の図として共有できるようにします。
PI Objectivesとは何で、なぜ重要なのですか? +
PI Objectivesは、各チームがPI Planningの最後にコミットする、SMARTでビジネス価値の重み付けがなされた目標です。フィーチャーを測定可能な成果に変換し、Business Ownersが成功度を評価する基準となり、Confidence VoteやInspect & Adaptイベントの土台にもなります。
PI PlanningのConfidence Voteとは何ですか? +
Confidence Voteは、PI Planningの最後に行う「フィスト・オブ・ファイブ」形式の投票です。参加者全員が、コミットしたPI Objectivesを達成できるという確信の度合いを5段階で示します。平均3以上であれば合意とみなされ、それを下回る場合はイベント終了前にプランを修正します。
リモートや分散のPI Planningは、対面とどう違いますか? +
リモートPI Planningはアジェンダこそ同じですが、複数日にわたる短い半日単位のブロックに分割し、付箋の代わりにデジタルボードを使い、タイムゾーンに配慮したスケジュールが前提になります。最大の違いはツールです。物理的な壁の代わりに、リアルタイムの双方向Program Board(JiraやAzure DevOpsと同期)を使います。
PI Planningを成功させるには、どう準備すればよいですか? +
PI Planningを成功させるには、開催前に3つの準備状況を確認します。組織面の準備(チーム、ART、Business Ownersのアラインメント)、コンテンツ面の準備(上位フィーチャーの優先順位付け、ビジョンとアーキテクチャのブリーフィングの用意)、そしてロジスティクス面の準備(拠点、ツール、コミュニケーションチャネルの確定)です。事前チェックリストがあれば、初日に想定外の事態が起きるのを防げます。
JiraやAzure DevOpsでPI Planningを実施できますか? +
はい。Kendisは、Jira、Azure DevOps、TFSとのリアルタイム双方向同期を提供します。フィーチャー、ストーリー、依存関係、PI Objectivesは、PI Planning中も実行期間中も、Program BoardとALMツールの間で常に同期され、手作業でのデータ移行は一切不要です。

ご質問はありますか?

アジャイルのスケールにおいてKendisが組織をどう支援できるのか、プロダクトエキスパートにご相談ください。
今すぐお問い合わせ 個別デモを無料でご提供します。



再生

動画を見る
プログラムレポートとアナリティクス

プログラムレポートとアナリティクス

Program Board上のすべての活動をグラフや表にまとめた総合的な概観により、Release Trainの完遂に向けて協働できます。

依存関係管理

依存関係管理

PIのすべての依存関係を、シンプルで意味のある1つの動的な仕組みに集約します。選択したトリガーに応じて、PI期間を通じて依存関係のステータスが自動更新されます。

リスクレジスターのトラッキング

リスクレジスターのトラッキング

Program Increment、スプリント、イテレーションにおける現在および今後のリスクを可視化して対処し、素早く特定してスムーズに軽減します。

フィーチャートラッキング

フィーチャートラッキング

スプリントやチームをまたいだフィーチャーの進捗、開発、追加、削除を、シンプルでわかりやすく可視化します。

スコープ変更のトラッキング

スコープ変更のトラッキング

プランニング後のPIのスコープやその他の変更を追跡し、何時間もの手作業を削減して、ヒューマンエラーの可能性をなくします。

ソリューション

Kendisは、アジャイルのスケールに必要なすべてを1つのソリューションで提供します

Kendisの中心にあるのは、コラボレーション、コミュニケーション、そして透明性です。煩雑な手間を大きく減らし、Program Incrementのプランニング全体を容易にします。
PI Objectivesのトラッキング
再生

動画を見る

依存関係は、進捗に影響する要因を認識し、特定し、正しくマッピングするうえで欠かせません。KendisではProgram Board全体で複数の依存関係を作成し、追跡できます。
依存関係管理
再生

動画を見る

Kendisなら、Program Increment、スプリント、イテレーションにおける現在および今後のリスクを透明性高く可視化し、特定と分析を無理なく行えます。
リスクレジスターのトラッキング
再生

動画を見る

チームごと、あるいはプログラム単位で目標を作成し、ボード上の任意のアイテムにひも付けられます。これにより、どのフィーチャーやストーリーが目標に貢献しているのかを正確に指定できます。
フィーチャートラッキング
再生

動画を見る

直近の活動をすべて俯瞰できる、非常に重要で強力な機能です。グラフや表の形式で表示されるため、必要な情報がひと目で手に入ります。
スコープ変更のトラッキング
再生

動画を見る


試してみる

始める準備はできましたか?

私たちは、お客様の優先事項を最優先します。
Kendisは、最も効率的なビジネス変革を実現する、最もスマートなスケーリングソリューションです。

今すぐ試す

無料クレジットカード不要。