- ストーリーポイントはまったく信頼できず混乱を招き、関係者にその意味を絶えず思い出させる必要がある
- 低いポイント値はより正確だが、高いポイント値は高い変動性を前提とし、範囲を示すため、正確に合算できない
- ストーリーポイントは時間を表さないが、ベロシティ指標と結び付くと事実上時間を意味するようになり、そもそも数値や範囲を足し合わせる行為を妨げる
- ソフトウェア見積もりは難しく、プロセスのアウトプットはインプットに比べて一般に有益ではない
- 妨害の少ない小規模チームは正確に見積もっているように見えるため、多くの場合、自分たちのやり方がうまくいっているという印象を与える
- Capacityが完全に使い切られると、すべての作業の変動性が急増し、あらゆる見積もりとタイムラインに急激な影響を与える
- 測定されたキューは短期および長期の見積もり問題を解決し、自然にスコープ変更を扱い、不確実性を取り除きながら、大規模チームにとってはるかに価値の高い実践を提供する
- 測定されたキューは、ベロシティやサイクルタイム関連の指標より20倍速く問題を予測する先行指標を提供する
ストーリーポイントとは何か？
- Atlassianによると、ストーリーポイントは、プロダクトバックログ項目またはその他の作業を完全に実装するために必要な総労力の見積もりを表す単位
- ポイントは複雑さ、作業量、リスクまたは不確実性、仕事の量を表す
- 複雑さの測定は相対的な概念であり、チームごとに同じ作業を異なるように評価することがある
- ポイントの相対的な性質により、チーム間比較は意味がなく、これは管理レベルでしばしば発生する問題
内在する変動性
- ストーリーポイントはフィボナッチ数列を基盤としており、値が高いほど変動性も大きくなることを示す
- 変動性の大きいポイント値を合算するのは無意味であり、ベロシティ指標でポイントを合算する行為は誤り
- グッドハートの法則によれば、測定が目標になった瞬間、その測定は良い測定ではなくなる
既知の問題点
- ストーリーポイントの問題は広く知られているが、代替となる見積もり技法も似た問題を抱えているため、依然として使われている
- ストーリーポイントの考案者であるRon Jeffriesはこれを否定し、誤用を批判している
- Scrumでは"Commitment"を"Forecast"に変更したが、それでもなお誤って使われている
- 見積もり以上の仕事をこなすと、かえって叱責を受けるという逆説的な状況が生じる
ROIで優先順位を付ける
プロセスの出力
- ストーリーポイント見積もりの過程には多くの時間を投じるが、出力には価値がない
- 定期的なグルーミングセッションは時間がかかり、チーム間で一貫性なくさまざまに適用される
- ストーリーポイントの代わりに意味のある作業リストを作成するほうが価値がある
代案の提示
- Tシャツサイズで見積もることはより良い代案になり得るが、これにも問題がある
- 時間で見積もることにも同様の問題があり、チームが実際に働く時間とビジネス側が期待する時間は異なる
- 小規模チームでは時間見積もりがうまく機能することもあるが、チームが大きくなると見積もりの精度は落ちる
- ドナルド・ライナートセンの『The Principles of Product Development Flow』で代案が提示されている
- 待ち行列（Queue）管理に焦点を当てて作業のフローを最適化することが核心
- キャパシティ計画を立て、変動性を受け入れられるバッファ容量を確保しなければならない
解決策
- チームが一緒に作業を分析し、小さなタスク単位に分割して不確実性を取り除くことから始める
- タスクリストは待ち行列（Queue）となり、総タスク数は作業量（Job Size）を表す
- Story Pointの代わりに平均タスク完了率（Average Task Rate）を使って見積もる
- 平均作業速度に基づいて作業を追跡し、作業完了率を計算する
- 新しい情報やフィードバックに応じてタスクを更新すれば、見積もりは自然に調整される
- 開発者は見積もりに対する心理的プレッシャーを受けずに済む
待ち行列（Queue）は先行指標
- 平均タスク完了率、Cycle Time、Velocityなどは後行指標である一方、Queueは先行指標
- Queueの規模が増加すれば、問題を事前に認識して対応できる
要約
- Story Pointは混乱を招き、信頼できず、失敗するように設計されている
- その代わり、チームが一緒に問題を理解し、不確実性を取り除き、タスク単位に分解してQueueを管理することに時間を投じるほうが、有意義で価値がある
GN+の意見
- 記事で示された待ち行列管理の方式は、アジャイル開発における見積もりの難しさを克服できる現実的な代替案に見える
- ただし、タスクを細かく分割する過程で開発者の負担が生じる可能性があり、プロジェクト初期段階ではより時間がかかるかもしれない
- また、タスク分析の過程では、開発者の積極的な参加と率直な意見表明が前提となる
- 一方で、開発チームがビジネス要件を深く理解し、共に考えるという前向きな効果も期待できる
2件のコメント
それってカンバン手法じゃないですか..?
Hacker Newsの意見
個人的な経験では、ストーリーポイントの数値自体は重要ではなかったが、チームが作業の複雑さを評価するプロセスは非常に有用だった
Scrumガイドで"Commitment"が"Forecast"に変更されたのは2011年ではない
作業パッケージを原子的な単位に分解し、キューの長さを測定することは別次元の問題である
ウォーターフォール方式と時間単位での見積もりがうまく機能する場合もある
ストーリーポイントは時間単位ではなく、相対的な複雑さと不確実性を表す
ストーリーポイントはおおよその時間単位だった
Scrumを初めて使ったときはRallyを使っていた
ストーリーポイントは作業の複雑さを議論するときには有用だが、速度を測るには不適切だった
ソフトウェア開発プロジェクトを信頼性高く見積もるのは難しい
時間単位で見積もる方がより良い方法である