はじめに
PBI(Product Backlog Item)には決まった書式がありませんが、実務ではユーザーストーリーという形式で書かれることが多くあります。本記事では、ユーザーストーリーの書き方の基本、その品質を測るINVEST基準、そして見積もりに使われるストーリーポイント・プランニングポーカーについて整理します。
ユーザーストーリーとは
ユーザーストーリーは、「誰が」「何を」「なぜ」求めているかを、機能そのものではなく利用者の視点から短く記述する形式です。代表的なテンプレートは以下の形です。
〜として(役割)、
〜したい(要求)、
なぜなら〜だからだ(理由・価値)
例:
家計簿アプリの利用者として、
カテゴリごとに色分けされたグラフで支出を見たい、
なぜなら、どの費目に使いすぎているか一目で把握したいからだ
技術的な実装方法(「どうやって作るか」)ではなく、「誰のどんな価値につながるか」を主語にして書く点が、通常の仕様書と異なるポイントです。
INVEST基準：良いユーザーストーリーの条件
書かれたユーザーストーリーの品質を評価するための基準として、INVESTという頭字語がよく使われます。
| 頭文字 | 内容 |
|---|---|
| Independent(独立している) | 他のストーリーへの依存が少なく、単独で着手・完成できる |
| Negotiable(交渉可能) | 詳細を固定しすぎず、実装方法について対話の余地を残しておく |
| Valuable(価値がある) | 利用者や顧客にとって明確な価値をもたらす |
| Estimable(見積もり可能) | チームが作業量をおおよそ見積もれるだけの情報がある |
| Small(小さい) | 1つのスプリント内で完成できる程度の大きさに分割されている |
| Testable(テスト可能) | 「完成したかどうか」を検証できる、明確な受け入れ基準がある |
大きすぎるストーリー(しばしば「エピック」と呼ばれる)は、この基準、特に S(Small) を満たせないため、着手前により小さな単位に分割するのが一般的です。
ストーリーポイントとは
ストーリーポイントは、ユーザーストーリー(PBI)の作業量を表す、相対的な見積もり単位です。時間(工数)そのものではなく、他のストーリーと比べてどれくらいの規模かという相対的な感覚で数値を割り当てます。
多くのチームは、数値としてフィボナッチ数列に近い値(1, 2, 3, 5, 8, 13...)を使います。数値の間隔を大きくすることで、「大きなストーリーほど、見積もりの誤差を大きめに許容する」という不確実性の性質を反映させています。
ストーリーポイントは絶対的な尺度ではなく、あくまでそのチーム内でだけ意味を持つ相対値です。あるチームの「5ポイント」と、別のチームの「5ポイント」を単純比較することはできません。
プランニングポーカーとは
プランニングポーカーは、チーム全員でストーリーポイントを見積もるための、合意形成の手法です。
進め方の基本
- 対象のユーザーストーリーについて、チームで内容を確認・議論する
- 各メンバーが、そのストーリーの規模だと思う数値のカード(1, 2, 3, 5, 8...と書かれたカード)を、他の人に見えないように選ぶ
- 全員が一斉にカードを公開する
- 全員の見積もりがほぼ一致していれば、その値を採用する
- 見積もりに大きな差がある場合、最大値・最小値を選んだメンバーがそれぞれの理由を説明し、再度議論・再見積もりを行う
この手法の狙いは、声の大きい人の意見に他のメンバーが引きずられることを防ぎ(一斉公開のため)、かつ見積もりの食い違いそのものを「認識のズレを発見する機会」として活用できる点にあります。オンラインチーム向けに、物理カードの代わりにWebツールを使う運用も一般的です。
まとめ
| 項目 | 内容 |
|---|---|
| ユーザーストーリー | 「誰が」「何を」「なぜ」欲しいかを利用者視点で書くPBIの記述形式 |
| INVEST基準 | 良いユーザーストーリーが満たすべき6つの性質(独立・交渉可能・価値・見積もり可能・小ささ・テスト可能) |
| ストーリーポイント | ストーリーの作業量を表す相対的な見積もり単位(絶対的な時間ではない) |
| プランニングポーカー | 全員が同時にカードを公開する形で見積もりの合意を形成する手法 |
プロダクトバックログ・PBIの基本概念については別記事「プロダクトバックログとPBIとは」、スクラム全体の役割・イベント・作成物については別記事「スクラムの基本を理解する」もあわせて参照してください。