nDiki : エピック

プロダクトバックログを分割詳細化した時にエピックを「残り」で残す

スクラムのプロダクトバックログリファインメントの時に、上位のプロダクトバックログはスプリントで完成させられるように分割詳細化していきます。

 |-- P1 (分割詳細化済み)
 |   |-- P1-1
 |   |-- P1-2
 |   `-- P1-3
 |-- P2 (一部分割詳細化済み)
 |   |-- P2-1
 |   |-- P2-2
 |   ...
 `-- P3 (未分割詳細化)

ツリーになるのだけれどどうするのが良いかなあという話になりました。大きな視点だと分割元もわかるようにしておきたいし、途中までしか分割されていないものはまだ残りがあることを忘れないようにしたい。

分割し残りがあるものは「残り」としてフラットにしてしまえばいいんじゃないということになりました。「残りプロダクトバックログアイテム」を作ればフラットなリストにしても漏れないよねと。

 |-- P1-1
 |-- P1-2
 |-- P1-3
 |-- P2-1
 |-- P2-2
 |-- P2-残り
 `-- P3

[ スクラム ]

2017年03月08日(水)の #nNote

プロダクトバックログアイテム

エピックに対する企画・調査をプロダクトバックログにのせるかどうか。

オポチュニティバックログを作らずシンプルに進めるなら、プロダクトバックログに。チームとして取り組まなければウォータースクラムになってしまうので注意。

ポートフォリオプランニングノート #nNote

ポートフォリオバックログアイテム

• プロダクト
• プロダクトのインクリメント(1回分のリリース)
• プロジェクト

など。以下プロダクト。

参加者

• 内部ステークホルダー
• 各プロダクトオーナー

インプット

• プロダクトプランニング(エンビジョニング)されたプロダクト
  • エピック(数カ月かかる複数回のリリースを含むユーザーストーリー)
  • 技術的課題解決で粒度の小さいものは入れない。「プランニングコストが高くなる」「ポートフォリオプランニングまで待ちになる」となるので。
• 仕掛中のプロダクト

タイミング

• 定期的に行う。

アウトプット

• ポートフォリオバックログ
  • 承認されているがまだ始まっていないプロダクト
• アクティブなプロダクト
  • 承認されてすぐ開発に入るプロダクト・続行が承認されたプロダクト

プロセス

インフローの管理

プロダクトの開発を進めるか中止するか判断する。

• コストをはるかに上回る価値を生み出せるか?

コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。 -- エッセンシャル スクラム

ポートフォリオバックログへの追加は年に1度ではなく、月に1回など。

小さめのリリースを頻繁に行うようなプロダクトのサイズにする。

スケジューリング (優先順位付け)

遅延コストに注意しながら、ライフサイクル収益(プロダクトの生存期間中に見込める利益の総計)の総量が最大になるように並べ替える。

• 遅延コストが大きいものを優先する。
• サイズが大きいものを優先する。
• 遅延コストとサイズが異なる場合については(遅延コスト/サイズ)で比較する。

アウトフローの管理

WIP を制限する。全員の準備が整ったチームに割り当てる。

仕掛かり中のプロダクトの管理


限界費用に注目して、継続・デリバリー・ピボット・打ち切りを判断する。

参考

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

関連

• ポートフォリオプランニング
• エッセンシャル スクラム 第16章 ポートフォリオプランニング

遅延コスト (Cost of Delay, CoD) #nNote

遅延コストの計算: アジャイルソフトウェア要求でフィーチャーの優先順位付けをする場合

「アジャイルソフトウェア要求」による計算方法では3つの属性の和

[ユーザー価値] + [時間値] + [リスク軽減値]

としています(それぞれ他のフィーチャーとの相対値で10が最高、1が最低)。

• ユーザー価値: ユーザーの目から見たフィーチャーの潜在的な相対的な価値。
• 時間値: ユーザー価値が時間とともにどのように減少するかの相対的な見積もり(価値が急速に低下するなら高)。
• リスク軽減/機会の可能性の値: フィーチャーによってリスク軽減される、あるいは新たな機会を得るという相対的価値(大きなリスク軽減につながる可能性がある、新たな機会が得られ可能性があるなら高)。

遅延コストの計算: アジャイルソフトウェア要求でエピックの優先順位付けをする場合

「アジャイルソフトウェア要求」による計算方法では3つの要素の和

[ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

としています(値はそれぞれ 1, 3, 5, 8, 13, 20, 40, 100、あるいはその他の等級)。

• ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
• 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
• リスク低減/チャンス利用(RRV): 将来のエピックのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

遅延コストの計算: アジャイルエンタープライズの場合

「アジャイルエンタープライズ」による計算方法では4つの要因の和

[収益の増加] + [収入の維持] + [コストの削減] + [コストの回避]

としています(それぞれ週当たり/年当たりの金額)。それぞれの要因は下記です。

• 収益の増加: 新規または既存の顧客の売上が増えるアイデア。
• 収益の維持: 収益・市場シェアを維持するアイデア。
• コストの削減: 現在発生しているコストを削減するアイデア。
• コストの回避: 現在発生していないが発生する可能性のあるコストを削減するアイデア(罰金の回避など)。

プロダクトの遅延コストの算出方法を考える

WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。

エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。

アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。

プロダクトについて

• ビジネス価値(BV): 収益・シェア・コスト削減・顧客の囲い込み向上についての相対的な価値。
• 時間価値(TV): 時間が経つとどの程度価値が下がるかの相対的な価値。大きい値は価値が急速に低下することを表し、小さい値は安定していることを表す。
• リスク低減/チャンス利用(RRV): 将来のプロダクトのリスクを低減する価値があるか、他のビジネスチャンスを活かす価値があるかの値。

をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。

そして3つを足した

 [ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]

を遅延コスト(CoD)とします。

正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。

とりあえずやってまた考えるという感じかな。

• アジャイルソフトウェア要求

プロジェクトでみんなをバスに乗せるために書いておく項目リスト

みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。

項目名を整理して決めておくと楽なのでちょっと書き出してみました。

コンセプトシート

比較的軽量にまとめる時。

• タイトル
• 概要 (What)
• 目標 (Goals)
• 背景と目的 (Why)

プロダクトプラン

プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトビジョン
  • 概要
  • 目標
  • 背景と目的
  • 成果物
  • 完了条件
  • スコープ(含むの・含まないもの)
  • (opt) 依存するプロジェクト・制約条件
  • (opt) リスク
  • (opt) 予算
  • (opt) メンバ
• 概要レベルのプロダクトバックログ
• プロダクトロードマップ

ポートフォリオバックログアイテム

ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。

• プロダクト名
• プロダクトプラン
• 期間
• 遅延コスト(ビジネス価値・時間価値・リスク軽減/チャンスと利用)
• WSJF

プロダクトバックログアイテム

スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。

• プロダクトバックログアイテム名
• ユーザーストーリー(誰・概要と目標・背景と目的)
• 満足条件(あれば成果物を含む)
• サイズ
• レビュー方法

タスクチケット

ちょっとしたタスク。

• タスク名
• 概要
• (opt) 背景と目的 (概要で自明でない場合)
• (opt) 成果物/アクション (概要で自明でない場合)
• 完了条件
• 期日

プロジェクト憲章

• プロジェクト名
• 概要
• 目標
• 背景と目的
• 成果物
• 完了条件
• スコープ(含むもの・含まないもの)
• (opt) 依存するプロジェクト制約条件
• (opt) リスク
• (opt) スケジュール・期限
• (opt) 予算
• (opt) メンバ

備考

他には以下のような形式もあります。

• One Pager
• インセプションデッキ
• 製品要求仕様書 (PRD: Product Requirements Document)
• リーンキャンバス

[ プロジェクトマネジメント ]