スロットモンキースピン

ストーリーポイントとは何か?プランニングポーカーを含めて解説

2021年3月4日

ストーリーポイントの概要

ストーリーポイントとは、ユーザーストーリーを実装するのに必要なコストを見積もるための単位です。

ユーザーストーリーとは、システムがユーザーに対して提供する価値を自然言語で書いたものです。アジャイル開発において要件定義の代わりに用いられます。
「<who>として、<what>を達成したい。それは<why>だからだ。」といったテンプレートで表されます。

このユーザーストーリーについては以下の記事で解説していますので、ご参照ください。

ストーリーポイントは、スキルや経験の違いによる見積もりの差異をなくすために用いられます。

今回はユーザーストーリーをさらに深く理解するために、ストーリーポイントの算出の仕方や用いられ方を解説していきます。

どのようにストーリーポイントを使うのか

プランニングポーカー

プランニングポーカーのイメージ(画像はより)

ストーリーポイントを決めるには、プランニングポーカーというツールを使います。プランニングポーカーには、フィボナッチ数列が使われることが多くあります。
フィボナッチ数列とは、2つ前の数と1つ前の数を足して、0、1、1、2、3、5、8、13……のように続く数列のことを言います。

以下にプランニングポーカーを使ったストーリーポイントの見積もり方法を示します。

  1. ユーザーストーリーを洗い出します。
  2. ユーザーストーリーが完了となるための定義を明確にします。このとき、大きすぎると判断したユーザーストーリーは小さく分割します。
  3. 任意のユーザーストーリーのストーリーポイントを話し合って決めます。このユーザーストーリーのストーリーポイントが基準になります。
  4. プランニングポーカーを使って、残りのユーザーストーリーのストーリーポイントを順に見積もります。
    1. チームメンバーはそれぞれ、基準としたユーザーストーリーのストーリーポイントに対して、対象のユーザーストーリーのストーリーポイントがいくつになるかを相対的に見積もります。
    2. メンバーでそれぞれ見積もったストーリーポイントを一斉に提示します。
      このとき一斉に提示する理由は、一人ずつ出してしまうと、はじめに出したメンバーのストーリーポイントに、後から出すメンバーが影響されてしまう可能性があるためです。
    3. メンバー間のストーリーポイントに差異があった場合、一番大きなポイントを出したメンバーと一番小さなポイントを出したメンバーから、それぞれ根拠をヒアリングします。
    4. ヒアリングした内容を踏まえてそれぞれ再考し、あらためてチーム全員でストーリーポイントを一斉に出します。
    5. AからDをメンバー全員のポイントのズレがなくなるまで繰り返します。
  5. すべてのユーザーストーリーについて、プランニングポーカーを使ってストーリーポイントを算出します。

ベロシティとスプリント

見積もったストーリーポイントはベロシティを用いてスケジュールに反映します。
ベロシティとはチームの開発速度を表すもので、1つのサイクルあたりに提供できる作業量をストーリーポイントで表します。

ここで言う1つのサイクルのことを「スプリント」と呼びます。1スプリントを1週間としているチームもあれば、2週間としているチームもあります。
通常は1スプリントあたり4週間以内とされています。

例えば1スプリントが2週間でベロシティが40ポイントのチームの場合、ストーリーポイントが8ポイントのユーザーストーリーを、2週間で5件分消化するようなスケジュールを立てることになります。

なぜストーリーポイントを使うのか

ストーリーポイントは、時間見積もりと比較されることが多いです。

時間見積もりの場合、見積もる人間の経験やスキルによって大きな差が出てしまいます。

例えば、ログイン機能を作るのにかかる時間をヒアリングしたら、ベテランのエンジニアは1日で完成できると言います。
一方、経験の浅いエンジニアは3日かかると言います。新入社員に至っては1週間かかると言われることもあるでしょう。

さらに、見積もりを行う人間と実装する人間が違う場合、実装を開始して初めて、スケジュールどおりに進めることができないと気づく場合もあります。時間見積もりを行う場合、見積もりと実装は同一人物でやらなければ、正確な見積もりは困難です。

一方、ストーリーポイントによる見積もりであれば、

  • 基準となるユーザーストーリーのストーリーポイントに対する相対見積もりであること
  • チーム全員でズレが生じなくなるまで繰り返し議論すること
  • 見積もったストーリーポイントは個人の技量ではなく、ベロシティというチームの開発速度に準じてスケジューリングされること

上記の理由から、時間見積もりのような差異は発生しにくく、また、メンバー間の認識の齟齬も起こりにくいと言えるでしょう。

参考

書籍

  • 鈴木安而『図解でわかるアジャイル・プロジェクトマネジメント』エスシーシー、2016年。
  • 市谷聡啓、新井剛、小田中育生『いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法』インプレス、2020年。

Webページ