Story Pointsの問題：エンジニアリングチームのためのより良い代替案

Story pointsはアジャイル開発における作業見積もりの事実上の標準となりました。どのエンジニアリングチームの計画会議に入っても、タスクが3なのか5なのか、またはその「シンプルな」機能がなぜか8になってしまった理由についての議論を聞くことになるでしょう。

しかし、ここに不快な真実があります：story pointsはしばしば解決するよりも多くの問題を作り出します。チームが見積もりに苦労するのを何年も見てきた後、エンジニアリングチームが実際に価値を提供するのに役立つより良い代替案を探る時が来ました。

Story Pointsが不十分な理由

精密性の錯覚

Story pointsは時間ベースのコミットメントのプレッシャーなしに相対的な見積もりを約束します。理論的には、5ポイントのストーリーは2ポイントのストーリーの約2.5倍の時間がかかるはずです。実際には、この関係はほとんど成り立ちません。

このシナリオを考えてみてください：あなたのチームはユーザー認証機能を5ポイントと見積もりました。後で、決済統合を5ポイントと見積もります。これらは本当に複雑さにおいて同等でしょうか？認証は単純なCRUD操作を含むかもしれませんが、決済統合にはサードパーティAPI統合、セキュリティコンプライアンス、エラーハンドリングが必要です。

ゲーミングとベロシティシアター

Story pointsが重要なメトリクスになると、チームは必然的にシステムを操作します。開発者はベロシティをよく見せるために見積もりを膨らませます。マネージャーはstory pointsが絶対的ではなく相対的であることを理解せずに、チームにベロシティの向上を圧力をかけます。

これは「ベロシティシアター」を作り出します - 実際の生産性インサイトを隠しながら進捗測定の錯覚を作り出します。今回のスプリントで50ポイントを完了したチームが前回のスプリントの40ポイントと比べて必ずしも改善したわけではありません；単に見積もりを再調整しただけかもしれません。

Planning Pokerの問題

Planning pokerセッションは魅力的ですが、しばしば偽のコンセンサスの練習になります。最も大きな声が勝つか、チームは複雑さを真に評価するよりも対立を避けるために見積もりに収束します。

さらに悪いことに、これらのセッションは大きな時間を消費します。典型的な計画セッションは、機能が3ポイントか5ポイントかを議論するのに30分を費やすかもしれません - 実際の問題解決や作業をより小さく管理可能な部分に分割するのに使える時間です。

Story Pointsのより良い代替案

1. 明確な定義を持つTシャツサイジング

数値的なstory pointsの代わりに、明示的でチーム固有の定義を持つTシャツサイズ（XS、S、M、L、XL）を使用します：

• XS：シンプルなバグ修正や設定変更（< 1日）
• S：明確な要件を持つよく理解された機能（1-2日）
• M：いくらかの調査や調整が必要な機能（3-5日）
• L：複数のシステムにまたがる複雑な機能（1-2週間）
• XL：より小さな部分に分割が必要なエピック

このアプローチは偽の精密性を避けながら相対的サイジングの利点を維持します。チームは自然にXL項目が分割される必要があることを理解し、「3スプリントかかる8ポイントストーリー」問題を防ぎます。

2. Cycle TimeとLead Timeメトリクス

推定された複雑さではなく実際の配信時間の測定に焦点を当てます：

これらのメトリクスは見積もりの主観性なしに配信プロセスについての具体的なデータを提供します。実際のボトルネックを浮き彫りにします：遅いコードレビュー、長いQAサイクル、またはデプロイメントの摩擦。

3. スループットベースの計画

個別の項目を見積もる代わりに、チームが期間あたりにいくつの項目を完了するかを追跡します。このアプローチは見積もりの精度よりもフローに焦点を当てます。

例えば、チームが通常スプリントあたり8-12の小さな項目または2-3の大きな項目を完了する場合、それに応じて計画します。この方法は見積もりが本質的に不確実であることを認めながら、予測可能な計画を可能にします。

4. モンテカルロ予測

確率的予測を作成するために履歴データを使用します。チームが過去6か月間で類似の機能を3-8日で完了した場合、信頼区間で予測できます：

• 5日以内の完了50%の確率
• 7日以内の完了80%の確率
• 10日以内の完了95%の確率

このアプローチは偽の精密性の後ろに隠すのではなく、不確実性を受け入れます。

変化の実装：実践的アプローチ

小さな実験から始める

Story pointsを一夜で放棄しないでください。代わりに並行実験を実行します：

1. 週1-2：Story point見積もりを続けながら実際のcycle timeも追跡
2. 週3-4：配信パターンを監視しながら新しい作業にTシャツサイジングを試す
3. 週5-6：1つのチームまたはプロジェクトでスループットベース計画を実験

特定のコンテキストでの各アプローチの精度と有用性を比較します。

継続的改善に焦点を当てる

見積もり方法に関係なく、目標は配信能力の継続的改善であるべきです。定期的な振り返りは以下に焦点を当てるべきです：

• 今回のイテレーションで私たちを遅くしたものは何か？
• Cycle timeをどのように減らせるか？
• より一貫して配信するのに何が役立つか？

重要なことを測定する

ベロシティの代わりに、ビジネス価値と直接相関するメトリクスを追跡します：

• デプロイメント頻度：どのくらい頻繁に本番環境に出荷するか
• 変更のリードタイム：コミットから本番環境までの時間
• 平均復旧時間：どのくらい早く問題を修正するか
• 変更失敗率：問題を引き起こすデプロイメントの割合

これらのDORAメトリクスは、story point見積もりのオーバーヘッドなしにエンジニアリング効果についての実行可能なインサイトを提供します。

Story Pointsがまだ意味を持つ場合

Story pointsは普遍的に悪いわけではありません。以下の場合にはうまく機能します：

• 一緒に作業を分割することを学ぶ新しいチーム
• 相対的比較が役立つ高度に不確実なドメイン
• 共通の見積もり言語が必要なチーム間調整
• ビジネスパートナーが概念を理解しているステークホルダーコミュニケーション

鍵は、精密な測定システムとしてではなく、会話と計画のツールとして使用することです。

結論

Story pointsは見積もり問題を解決することを約束しましたが、しばしば新しい問題を作り出します：偽の精密性、ゲーミング、時間のかかる計画儀式。代替案 - Tシャツサイジング、cycle timeメトリクス、スループット計画、確率的予測 - はエンジニアリング作業の計画と測定により実践的なアプローチを提供します。

最高の見積もりシステムは、チームが意思決定を行い配信を改善するために実際に有用だと感じるシステムです。継続的改善に焦点を当て、重要なことを測定し、目標は完璧な見積もりではなく、効率的で予測可能に顧客に価値を提供することであることを覚えておいてください。

小さく始め、異なるアプローチで実験し、チームがより良いソフトウェアをより速く出荷するのに役立つ方法を選択してください。将来のあなた（とあなたのチーム）は、story pointの罠を超えたことに感謝するでしょう。