[ooaa main]  [object pasta2]   [essence] (旧blogはこちら)  [flickr]  [myspace]  [View Eiichi Hayashi's profile on LinkedIn] 

スクラムのバックログ優先順位についてのメモ:

マイクコーンは「変化を受け入れないでいられる期間をスプリント期間として定める」(翻訳Ryuzeeさん )と言ってる。

スプリント期間に変化を受け入れないという制約から、バックログの優先度の設定はこのことを踏まえた戦略的な決め方が必要になってくる。

ROIが高くて、スプリント期間に変化する可能性が低ければ、そのままスプリント計画に組み込めばよいが、ROIが高くて、スプリント期間に変化する可能性が高い場合は、作り直しのリスクによる期待コストをROI(コスト対効果)の中のコストに加味して考える必要がある。

ROIが高くてビジネス上の優先度が高いもの(これを仮に”バックログ項目A”とする)が、変化のリスクを過大評価して、実施優先度を下げることでのデリバリー遅れのリスクと、着手しないことによるその項目固有の実現リスクがクリアされない問題が発生する。

この矛盾を解決するために、”バックログ項目A”の実現のためのリスクがクリアができる最低限の項目を切り出して、”バックログ項目A”を分割して、スプリントに組み込むことが可能である。(例えば、機能なしUIの流れだけを確認とか、ポイントになる処理部分だけを実装するなど、)

優れたプロダクトオーナーはこのことを意識せずに自然に実行している。

スクラムマスターは、プロダクトオーナーがこの判断を十分に行えていないと感じたら、この戦略を、バックログの分割指針をチームに示唆することで提案することができる。