大きなユーザーストーリーのこと。おおよそ数カ月程度の大きさで複数回のリリースがあるもの。プロダクトプランニングで議論する際に使用し、ポートフォリオバックログで管理する。
大きさとしては以下の順になる。
「エピック(数カ月程度)」 > 「フィーチャー(数週間程度)」 > 「スプリント可能なストーリー / 実装可能なストーリー」
スクラムのプロダクトバックログリファインメントの時に、上位のプロダクトバックログはスプリントで完成させられるように分割詳細化していきます。
|-- 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
[ スクラム ]
エピックに対する企画・調査をプロダクトバックログにのせるかどうか。
オポチュニティバックログを作らずシンプルに進めるなら、プロダクトバックログに。チームとして取り組まなければウォータースクラムになってしまうので注意。
など。以下プロダクト。
プロダクトの開発を進めるか中止するか判断する。
コストや価値に関するちょっとした見解の相違で言い争いになって決断ができないのだとしたら、そのプロダクトの開発は却下すべきだ。 -- エッセンシャル スクラム
ポートフォリオバックログへの追加は年に1度ではなく、月に1回など。
小さめのリリースを頻繁に行うようなプロダクトのサイズにする。
遅延コストに注意しながら、ライフサイクル収益(プロダクトの生存期間中に見込める利益の総計)の総量が最大になるように並べ替える。
WIP を制限する。全員の準備が整ったチームに割り当てる。
限界費用に注目して、継続・デリバリー・ピボット・打ち切りを判断する。
「アジャイルソフトウェア要求」による計算方法では3つの属性の和
[ユーザー価値] + [時間値] + [リスク軽減値]
としています(それぞれ他のフィーチャーとの相対値で10が最高、1が最低)。
「アジャイルソフトウェア要求」による計算方法では3つの要素の和
[ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]
としています(値はそれぞれ 1, 3, 5, 8, 13, 20, 40, 100、あるいはその他の等級)。
「アジャイルエンタープライズ」による計算方法では4つの要因の和
[収益の増加] + [収入の維持] + [コストの削減] + [コストの回避]
としています(それぞれ週当たり/年当たりの金額)。それぞれの要因は下記です。
WSJF (重み付けされた最短の作業から着手)という手法を使い始めるにあたり遅延コストを算出方法を見直し中。
エッセンシャル スクラムでは遅延コストの出し方をいくつか紹介しています。その中の1つ「アジャイルソフトウェア要求」で提案している3つ要素の和として決める方法をまずは使おうと思っています。
アジャイルソフトウェア要求では「フィーチャーの優先順位付け」と「エピックの優先順位付け」のところでそのやり方が出てきますが、今はポートフォリオプランニングレベルで考えているのでエピックの方が考え方として近そう。
プロダクトについて
をフィボナッチ数列の値で相対的に見積もります(アジャイルソフトウェア要求だと 1, 3, 5, 8, 13, 20, 40, 100 という等級を例として出しています)。
そして3つを足した
[ビジネス価値] + [時間価値] + [リスク低減/チャンス利用]
を遅延コスト(CoD)とします。
正直なところ「金額」と「金額変化度合い」とをごっちゃに足しちゃう気持ち悪さがあってちょっとすっきりしない感じはあります。あと3要素それぞれで相対で決めていくとすると、特定の要素が大きめになって遅延コストを支配する可能性も出ちゃいそうだなと。
とりあえずやってまた考えるという感じかな。
みんなをバスに乗せるためにプロジェクトのプランニングで明確にして共有した方が良いドキュメント形式って、方法論やプロジェクトの段階によっていろいろな名前のものがありますが、基本的に項目はどれも似たような感じです。
項目名を整理して決めておくと楽なのでちょっと書き出してみました。
比較的軽量にまとめる時。
プロダクトプランニング(エンビジョニング)のアウトプットとして。エピックレベル(数カ月程度の大きさ)。
ポートフォリオプランニングで、プロダクトプランを評価した結果のもの。エピックレベル(数カ月程度の大きさ)。
スクラムで1スプリントで完成できるサイズのアイテム。フィーチャーレベル。
ちょっとしたタスク。
他には以下のような形式もあります。
[ プロジェクトマネジメント ]
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。
ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。