ストーリーポイントの見積もり方：プランニングポーカーの実例

ストーリーポイントによる見積もりでは、あるバックログ項目を完了するための労力を、チームが理解している別の作業と比較します。プランニングポーカーを有意義に進めるには、尺度を決め、基準となるストーリーを選び、見積もりを同時に公開し、差が大きい理由を話し合って、範囲を明確にしてから見積もり直します。

スプリント計画に使うスクラムボードがあれば、ストーリー、比較の基準、疑問点を見ながら話し合えます。ここでは購入手続きを担当するチームが3つの項目を見積もる例を取り上げます。そのうち1つは依存関係が未解決のため、見積もりを保留します。

比較できるストーリーを用意する

ストーリーポイントは、作業量、複雑さ、不確実性を含む相対的な労力を表します。Mountain Goat Softwareによる説明では、チームの「完成の定義」を満たすために必要な作業も含めます。完了にテスト、結合、文書化が必要なら、実装だけを見積もるわけにはいきません。

会議の前に、各ストーリーでユーザーが得る結果と、話し合いに必要な受け入れ条件を明らかにします。重複をなくし、関係のない目的を分け、作業に影響する依存関係を確認してください。「注文の概要を表示する」だけでは、含まれる項目、状態、データの取得元が分からず、見積もりの意味も曖昧になります。

この例では、次の3つを持ち寄ります。

• 保存済みの住所の名前を「住所1」から、購入者が指定したラベルに変更する。
• 外部の住所検証サービスで郵便住所を確認し、問題があれば購入者に伝える。
• 購入手続きの完了後、注文サービスがすでに返している項目を使って注文確定の詳細を表示する。

見積もるのは、その作業を行う人です。プロダクトオーナーは期待する動作と範囲を説明し、ファシリテーターは話し合いを進めて疑問点を記録します。スクラムではバックログ項目の規模を見積もる責任は開発者にありますが、特定のポイント尺度やプランニングポーカーの使用が定められているわけではありません。

基準となる項目と一つの尺度を決める

このチームは1、2、3、5、8、13を使います。投票の前に尺度を選び、同じ値の組み合わせを一貫して使ってください。ほかの尺度も使えますが、同じ会議の途中で切り替えると比較しにくくなります。

基準にするのは完了済みの2件です。一つは保存済み住所のラベル編集で2ポイント、もう一つは新しいサービスの動作と複数のエラー状態を伴う配送方法の変更で8ポイントでした。数字の横に、作業範囲と完了条件も残します。基準が役立つのは、その作業をチームが覚えているからであり、「2」という数字だけに意味があるからではありません。

新しいストーリーは小さな編集と大きな連携作業のどちらに近いか、その理由とともに考えます。1ポイントを固定の時間数と定義しないでください。8ポイントの項目は2ポイントより総労力が大きくても、完了までの日数が4倍になるとは限りません。担当者の稼働状況、並行作業、依存関係が経過時間に影響します。

最初は各自で見積もる

項目を読み上げ、誰かが数字を出す前に、プロダクトオーナーが範囲に関する質問に答えます。その後、各自がほかの人に見えない形で値を選びます。同時に公開し、最小と最大の値を選んだ人に、どの作業を含めたかを聞き、ほかの参加者も不足している前提を補います。これがMountain Goat SoftwareのPlanning Pokerガイドに示された基本的な進め方です。

4人が保存済み住所のラベル変更を見積もり、2、2、3、3になったとします。低い値の人は表示ラベルだけの変更を想定し、高い値の人は住所の検証処理の変更も含めていました。プロダクトオーナーが、検証処理と配送の動作は変えないと確認します。チームは2ポイントの基準と比較して再投票し、2で合意します。

納期に合わせて見積もりを下げたわけではありません。もともと範囲に含まれない作業を除いた結果です。見積もりの横に「ラベルのみ。検証処理は変更なし」と残せば、会議にいなかった人にも境界が伝わります。

数字を確定する前に見解の違いを解く

住所検証の項目では5、5、8、13になりました。最小の見積もりは、既存のサービスが外部サービスからの応答を処理すると想定しています。最大の見積もりには、タイムアウトへの対応、外部サービスが利用できない状態、未検証の住所でも先に進めるかという新たな判断が含まれています。

ここで分かったのは、プロダクト上の未決事項と技術的な不明点です。平均を取ったり、両端の間だからと8を選んだりはしません。まずプロダクトオーナーが検証できない場合の動作を決め、エンジニアが現在の連携処理を調べます。この2つの問いと担当者を付けて、項目をリファインメントに戻します。調査が必要なら、機能全体の完成を約束するのではなく、答えるべき問いを明確にした別の作業として計画できます。

注文確定の表示では、最初の投票が3、3、5、5になりました。高い見積もりには、ストーリーに書かれていない領収書のダウンロードが含まれていました。プロダクトオーナーは、既存の注文番号、商品、合計、配送方法を表示し、領収書のダウンロードは別の作業だと説明します。データがない状態と読み込み中の状態も考慮して再投票し、3で合意します。

合意した値は、改めて話し合って投票した結果であり、最初の投票の平均ではありません。このチームの尺度に4はないため、3と5に分かれたからといって自動的に4ポイントにしません。差が縮まらない場合は、無理に精密な数字を作らず、何が不明なのかを記録します。

見積もりと残った問いを記録する

見積もった項目には、合意した値、その値に影響した範囲の判断、比較に使った基準のストーリーを残します。保留した項目には、問いと回答する担当者を記録します。住所検証のストーリーを0ポイントにしたり、ボードから消したりすると、未解決の作業が見えなくなります。

この例で合意した2件は合計5ポイントですが、それだけでスプリント中の完了を約束したことにはなりません。スプリントプランニングでは、スプリントゴール、利用できる稼働時間、依存関係、チーム自身の過去の実績も考えます。別のチームのポイントを足したり、完了ポイントで開発者同士を比較したりしないでください。尺度は、そのチームの作業に対する共通理解に基づいています。

後から範囲が「既存の項目を表示する」から「領収書を作成してダウンロードする」に変わったら、項目と見積もりを見直します。以前の範囲の記録も残し、変更を追えるようにします。作業が変わったときの再見積もりには意味がありますが、過去の計画を正確に見せるために黙って数字を書き換えると、学びに必要な情報が失われます。

Boardmixに見積もりの話し合いをまとめる

基準のストーリー、現在のストーリー、公開済みの見積もり、合意した範囲、未解決の問いを置く領域を作ります。2つの基準は全員が見られる場所に置きます。現在の項目については、投票の前にユーザーが得る結果と受け入れ条件を示してください。

各自の値を伏せて同時に公開できる物理的なカードやツールを使い、公開した値をボードに記録します。全員が選ぶ前に共有キャンバスへ数字を書くと、後から選ぶ人に影響する場合があります。この使い方でBoardmixが担うのは、ストーリーと話し合いの記録を共有する場所です。非公開での投票は別に行います。

Boardmixのボードを開き、基準の項目と購入手続きの3つのストーリーを並べてみてください。数字だけを残すのではなく、各項目の横に「2：ラベルのみ」「保留：外部サービスが使えない場合の動作を確認」「3：既存の注文確定項目」と記録します。