0時に寝て6時に起きた。

ストーリーポイント再考⌗

スクラムのふりかえりイベントでストーリーポイントの見直しをしようという話題が出た。この半年ほどストーリーポイントを使って実際に開発をやった事実から整理してみる。

  • 開発者のタスクも非開発者のタスクも同じ尺度のストーリーポイントを設定していた
  • あるチケットのタスクをやっていてチケット分割すると、最低でもストーリーポイントが1増えていた
    • 元チケットと分割したチケットのストーリーポイントの総数が同じであれば問題はないが、ストーリーポイント1が設定されたチケットを2つに分割するとそれぞれにストーリーポイント1をセットしても2倍になってしまう。タスク分割したのにストーリーポイントをゼロにセットするのもなんか違う
  • ストーリーポイントの数値からバーンダウンチャートを生成した (みえる化)
    • このバーンダウンチャートで運用して実際に2回の延期が発生し精度が低いことがわかった
      • 納期の2週間前に延期することがわかった
      • シニア開発者の勘と経験の方が精度が高かった

これらの事実から私の所感をまとめてみる。

  • 開発者と非開発者 (プロダクトオーナー) の業務を同じ数値で表して合算するのは論理的におかしい
  • 複雑な業務の開発プロジェクトでストーリーポイントの数値を設定するのは難しい
    • 複数のマイクロサービスを担当
    • 複数の技術領域を担当 (インフラ、フロントエンド、バックエンド、要件定義)
  • チケット駆動開発と相性が悪い
    • チケット分割は担当者がタスクを完了させやすい粒度や内容で分割すればよかったのがストーリーポイントを考慮すると複雑さが増す
    • チケットの粒度はチームで統一されているのが理想的ではあるが、現実的にそのような運用の統制が取れているのを私はみたことがない
      • チケットの粒度とストーリーポイントの合計に相関が出てしまい、それは個人差 (属人化) が生じやすい
  • 安易なみえる化による弊害がある
    • ストーリーポイントは開発の状況を表す指標の1つではあるが、現実をすべて表しているわけではない
    • 多次元的なパラメーターからストーリーポイントというただ1つの指標を用いて2次元にすることで他の情報が欠落する
      • 偏ったデータによる意思決定に使われる懸念がある (その情報を外部に発信していればとくに)

ストーリーポイントによる運用をうまくまわすにはいくつか制約があるように私からは思えた。

  • 開発プロジェクトのスコープや業務内容が一定の複雑さにおさめられる
    • 一定の制約や制限がないと論理的に説明可能な適切な数値を割り当てられない
    • 例) 外部要因に影響をうけない1つのマイクロサービスを開発する
    • 例) 開発者はフロントエンドだけの開発をする
  • 開発者と非開発者のタスクは別で管理する (合算しない)