DaisukeのITメモ

一人前になる為に。

ProductBacklogの優先順位の決め方_WSJF

目次

概要

ProductBacklogの優先順位を決める際の考え方やフレームワークはいくつか存在する。
そこで今回は、その中でも主流なWSJFについて纏める。

【復習】ProductBacklog（PBL）とは？

  • ScrumにおいてPOが作成,管理するモノ。
  • ProductBacklogItem（PBI）のリスト。
    • PBIには、ユーザーストーリー形式で要件が記載されている。

【大前提】なぜ優先順位を決める必要が有るのか？

  • プロダクトはユーザに使ってもらって始めて価値を発揮するため、てきとうな順番で機能を実現してユーザに届けるのではなく、より価値有るものがより先（早く）にユーザに届くように考える必要が有る。
    • 例えば、毎月300万円の価値が有るプロダクトのリリースを3ヶ月遅らせる事で生じる損失は、900万円（300万円 × 3ヶ月）。
    • 一方で、毎月50万円の価値が有るプロダクトの場合、150万円（150万円 × 3ヶ月）。
    • 上記の様な考え方をCoDと言う。
  • また、下記2つの観点で仮説度が大きいモノは、より早くリリースし、仮説検証を行う方が良い。
    1. 技術的実現性（フィージビリティ）
    2. ビジネス的需要性,収益性（ユーザに受け入れられるか？売れるか？）

CoD（Cost of Delay）とは？

  • デリバリーを遅らせたせいで損するコスト（実現できなかった価値）の事で、「遅延コスト」と呼ばれる。
  • 下記の3つの要素から成る。
    1. ユーザ,ビジネス価値
      • ユーザやビジネスに提供する価値。
      • ユーザに提供できる価値や、我々の収益に与える価値が大きなPBIは、なるべく早くリリースすべき。
    2. 緊急性（時間的制約）
      • ユーザ,ビジネス価値は、時間が経過すると小さくなる。
      • 決まったデッドラインが存在したり、競合との競争性が有るPBIは、なるべく早くリリースすべき。
    3. リスク低減
      • フィージビリティーリスク（技術的実現性）やユーザ,ビジネス価値リスク（本当に需要が有るのか等）を早期に発見,解決する為に、仮説性が高いPBIはなるべく早くリリースするべき。

純粋にCoDがより大きいモノから早くリリースすれば良いのか？

  • 答えは「No」。
  • Q：下記の様な場合において、どの様な順番で着手（実現）すべきか？
    1. 機能A
      • 価値（CoD）：5
      • 作業時間：5
    2. 機能B
      • 価値（CoD）：2
      • 作業時間：10
    3. 機能C
      • 価値（CoD）：10
      • 作業時間：500
  • A：１、２、３の順に着手（実現）するのが、トータルで得られる価値が1番大きい。
  • つまり、CoDだけではなく、作業時間（JobDuration）も考慮して、PBLの優先順位を決める必要が有る。

WSJF（Weighted Shortest Job First）とは？

  • SAFe(Scaled Agile framework)で用いられているフレームワーク。
  • 「重み付けされた最短の作業から着手する」という考え方。
    • 簡単に言うと、「コスパ良いタスクから着手しよう」という考え方。
  • PBI毎に下記式を計算し、値が大きい順に優先順位を付ける。
    • WSJF = CoD / JobDuration
  • CoDとJobDurationの見積もりには、相対見積もりを用いる。
    • どちらの概念も、定量的に見積もり,評価する事が難しいため。
    • Sprintをこなす毎に、相対見積もりの感覚値や考え方を振り返ってブラッシュアップしていく事が大切。

参考文献

所感

  • CoD3要素を相対見積りする際の考え方や基準が非常に重要そう、かつ、難しそうなので、既に優先順位付け,リリースしたPBIとそのビジネス的実績を基にFBを繰り返していく事が非常に重要と考える。
/* -----codeの行番号----- */