nDiki : エピック

エピック (epic)

大きなユーザーストーリーのこと。おおよそ数カ月程度の大きさで複数回のリリースがあるもの。プロダクトプランニングで議論する際に使用し、ポートフォリオバックログで管理する。

大きさとしては以下の順になる。

エピック(数カ月程度)」 > 「フィーチャー(数週間程度)」 > 「スプリント可能なストーリー / 実装可能なストーリー」

スポンサード リンク

2017年1月25日 (水)

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

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

 |-- 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月25日全て ]

2017年3月8日 (水)

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

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

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

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

[ 3月8日全て ]

2017年10月20日 (金)

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

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

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

など。以下プロダクト。

参加者

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

インプット

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

タイミング

  • 定期的に行う。

アウトプット

プロセス

インフローの管理

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

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

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

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

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

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

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

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

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

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


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

参考

関連

[ 10月20日全て ]

2018年6月6日 (水)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2018年6月7日 (木)

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

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

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

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

プロダクトについて

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

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

そして3つを足した

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

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

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

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

[ 6月7日全て ]

2018年7月27日 (金)

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

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

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

コンセプトシート

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

  • タイトル
  • 概要 (What)
  • 目的(と背景) (Why)
  • ゴール (Goals) and/or 目標 (Objectives)

プロダクトプラン

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

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

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

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

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

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

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

タスクチケット

ちょっとしたタスク。

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

プロジェクト憲章

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

備考

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

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

[ 7月27日全て ]

About Me

Naney Naney

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

最近検索されている記事

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

notes.naney.org 新着ノート

月別インデックス
Process Time: 0.052042s / load averages: 0.87, 0.74, 0.53
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker