はじめに
ストーリーポイントは見積もりの手段です。
ストーリーポイントは優れた見積もり手法であることは多くの書籍やエントリで説明されていますが、
2017年版のScrum Guideにおいてストーリーポイントという単語は存在しません。
Scrum Guideではプロダクトバックログアイテムの属性の1つして見積りが存在しその見積りの責任は開発チームが負うことが挙げられていますが、具体的な見積り方法は言及されていません。
ストーリーポイントはスクラムの必須要件ではないということが言えます。
見積り方法は現場の開発チームの状況やステークホルダーとの関係性の制約などを踏まえて合理的な見積もり方法をとることが求められます。
もっと言えばそこに合理性があるのなら見積もりをしないという選択をとってもよいはずです。
[Stop Using Story Points](翻訳エントリ)ではストーリーポイントを導入した経験則からもっとシンプルな手法で見積もりをすることを提唱しています。
筆者はこのエントリの主張には状況に応じて手段を更新している点で共感をしています。
しかし、依然としてストーリーポイントは有力な見積り方法の候補であるとも思っています。
本エントリーではScrumにおいてストーリーポイントもたらす効果を私なりに取り上げてみます。
ストーリーポイントにこだわらなくても他の手段で代替できる効果はあると思いますが、
見積り方法の判断に迷った時の参考になっていただけるといいなと思っています。
ストーリーポイントがもたらす効果
1. Acceptance Criteria(受け入れ条件)の認識合わせに寄与する
見積り時にチーム内でポイントがブレるときは受け入れ条件の認識がずれている可能性があります。
例えば比較的小さく見積もっている人は受け入れ条件で漏れがあったり、比較的大きく見積もっている人は潜在化した受け入れ条件が存在するかもしれません。
その気付きを誘発する1つの道具となるでしょう。
また、基準チケット(プロダクトバックログアイテムの相対評価基準)を定めていると効果的です。
筆者が過去いたチームでは複雑性・規模・曖昧性の3つの指標で基準がコミュニケーションされていました。
指標を定義することで議論スコープが定まり、認識合わせの助けになるとともに見積り時間を短縮することができました。
一方で、メンバーそれぞれが持っている情報や捉え方が異なっていると認識合わせに時間がかかります。
見積り自体チーム内で頻繁に行われていて情報同期が行われている状態でないと得られるリターンは少ないでしょう。
2. プロダクトバックログの優先順位決めに寄与する
ストーリポイントの大小はビジネス優先順位に影響します。
同じビジネス価値が想定できるプロダクトバックログアイテムがAとBあった時、Aの方がBよりもストーリーポイントが大きい場合はBの優先度をあげることになるでしょう。
プロダクトバックログアイテムのストーリーポイントがとても高い場合は何らかの不確実性や制約が潜在している可能性があります。
もしそのプロダクトバックログアイテムを優先させたい場合はチケットの分割をし、分割したチケットの優先度を上げてこなすことで不確実性に立ち向かうことになるでしょう。
3. ベロシティ測定に寄与する
スプリントでAcceptedしたプロダクトバックログアイテムの合計ポイント数がベロシティとして換算され、
次回以降のスプリントでだいたいどの程度のプロダクトバックログがAcceptedになるかの見通しを付けビジネスをコントロールすることができます。
とはいえビジネス変化が盛んな場合1~2スプリントで状況が変わることは往々にしてあるので、あまり遠い未来を予測してもその予測と実態は異なることもあるのであくまで目安とするのがよいでしょう。
しかし、ベロシティは非常に脆く無常なものです。
チームの見積りの練度が上がっていないとベロシティが参考にしづらいです。
undoneが存在する場合はどのように取り扱うかを決めておかないとAcceptedはしてもリリースはできずベロシティの見かけとデリバリしている価値の相関が取れなくなります。
さらに、開発チームへの増員があればベロシティは参考情報にならなくなります。
人員計画を握っておかないと得られる効果が少なくなります。
4. スプリントプランニングの高速化に寄与する
過去のベロシティの経験則が参考になる場合は、ベロシティ値程度になるようにプロダクトバックログの優先順位が上の方から選択することでプランニングするスコープを簡単に選択することができます。
事前にプロダクトオーナーとチームで話し合ってプロダクトバックログを優先順位にソートしていないとスコープ選択にコストを支払うことになります。
Stop Using Story Pointsで紹介されている事例のアンチパターン
不合理なストーリーポイントのインフレ
ベロシティを会社のインセンティブに紐づけてしまったのが原因だと思われます。
これでは効果の1,3,4が享受できません。
予測可能性のために品質を犠牲にする
ベロシティを保持することが目的化してしまっているのが原因だと思われます。
プラクティス自体が目的になってしまったパターンと言えるでしょう。
技術的負債などのシステムの問題点や制約を透明化することは開発チームの責任です。
ポイントでチームを比較する
ポイントでチームを評価してしまうと上記の2つのような誤用が生まれるリスクがあり、
享受できるメリットが減少すると思われます。
まとめ
ストーリーポイントで得られる効果をまとめました。
しかしそれを享受するには一定数の運用コストを支払う必要があるし、アンチパターンにならぬよう運用をしていく難しさがあります。
人は図らずも身近なものさしで測ってしまうこともあるでしょう。
ベロシティが上がらないときには他の開発チームのそれと比較したい気持ちも分かります。
現場が見えていない時に定量的なベロシティを頼りに評価をしてしまうこともあるでしょう。
こういうところからアンチパターンに陥ります。
忍耐強くアンチパターンを回避するに値する効果が得られる手法なのかは考え続ける必要があります。
ストーリーポイントは見積もりの手段でしかないので、ROIをみて最適な見積り方法を選択しましょう。
