ストーリーポイントに関する15個のよくある質問と答え

 2011/04/10

Questioning Story Pointsが良い記事だったので適当に抜粋意訳。 もっと細かく知りたい場合はアジャイルな見積もりと計画づくりを読もう。

1. ストーリーポイントとは何か?

ストーリーポイントはユーザーストーリーを見積もるためにチームが使う架空の単位である。

2. ストーリーポイントは何を表すか?

ストーリーポイントはユーザーストーリーを実装するのに必要な作業量を表す。アジャイルな人の中には、ストーリーポイントは複雑さの指標である、という人もいるが、ユーザーストーリーを実装するに際しての複雑度やリスクがその実装において考慮されている場合のみあてはまると言える。

3. ストーリーポイントの見積もりには何が含まれているのか?

ストーリーポイントの見積もりには、そのストーリーを「完了」にするために必要なすべての作業が含まれているべきである。ここでいう「完了」の定義(Definition of Done)は理想的には、ストーリーを実装するのに必要な開発作業とテストの双方が含まれているべきである。ユーザーストーリーが実装された、ということは本番環境で利用可能ということであるべきだ。(テストが残っているべきではない)

4. 日にちや時間で見積もるのより何故ストーリーポイントの見積もりが良いのか?

ストーリーポイントは既に見積もったストーリーをサンプルとして比較しながら相対的なサイズを算出することで行われる。ストーリー間での相対的なサイジングは個々の独立したストーリーを個別に見積もるよりもより正確な結果となる傾向にある。

たとえば、デリーからバンガロールまでの距離はムンバイからバンガロールの距離の2倍である、というのは、デリーからバンガロールの距離は2061kmであるというのに比べるとはるかに簡単だ。

チームはそれゆえに個々のユーザーストーリーを完了させるのに必要な日時や時間を正確に算出するのに多くの時間をかけることなく、より簡単に見積もりを行うことができる。

5. どうやってポイントで見積もるのか?

見積もりをする一般的な方法は、ストーリーを1,2,4,8,16等に分類することである。1,2,3,5,8といったフィボナッチ数列の値を使うことを好むチームもある(訳注:基本的にフィボナッチであるべきだと思う…) 見積もり対象のストーリーを用意したら、チームは一番小さいと思うストーリーからサイジングを行う。

例えば、チームはユーザーがログインするストーリーを選択し、それを2ポイントとした。続いて顧客の検索のストーリーを選択したが、それは先に見積もったログインストーリーの2倍くらいの作業量が必要だと考え4ポイントと見積もった。この作業は全てのストーリーに見積もりが付与されるまで行う (訳注:全部を見積もる必要は必ずしもない。優先度の高いストーリーは必ず見積もられるべきだが、優先度が低いストーリーは本当に実装するか分からないし、ストーリーの要件が明確でないケースもある。)

6. ストーリーポイントの見積もりは誰がやるべきか?

ストーリーを「完了」にする責任をもつチーム自身が見積もりを行う。もしチームにストーリーをテストしたりテスト自動化を行うQAのメンバーがいる場合は、彼らもチームと一緒に見積もりを行う。

QAは開発にはそんなにかからない、とかテストはもっとかかる等と言うことが出来るべきである。 例えば、チームは顧客検索の画面は4ストーリーポイントで2つの新しいブラウザへの対応は1ポイントだと考えたが、QAとしてはテストにもっとかかるという意見を言うことができ、見積もりに際してはQAはそれを反映した数字を出すことになる。

7. ストーリーポイントを時間や日数にどうやって変換するのか?

ストーリーポイントについては変換を行うべきではない。ストーリーポイントはベロシティと密接に関係しており、各イテレーションの最後にチームが完了したストーリーポイントの数でもってベロシティを測定する。

8. ポイントで見積もる場合に、うまくいく場合、まぁまぁの場合、うまくいかない場合のそれぞれのケースで見積もるべきですか?

うまくいった場合、まぁまぁの場合、うまくいかない場合の3通りの見積もりをそれぞれのストーリーで行うこともありかもしれない。これはまだコード量が少なくいような初回リリースまでの間で大量のストーリーを見積もらなければならないようなケースでは効果があるだろう。

こうすることによって、チームが考えた想定事項次第で変化する見積もりの範囲を明らかにできるだろう。 例えば、ユーザーログインのストーリーにおけるベストケースはローカルのLDAPサーバと接続することで実装する案で2ポイントだが、想定が崩れてサードパーティ製の認証プロバイダを利用する場合は最悪で8ポイントになる、といった具合だ。

9. ストーリーポイントを使ってどうスケジュールや計画をたてるのか?

ストーリーポイントをスケジュールに変換するためには、チームは自分たちのチームが1イテレーションあたりにデリバーできるストーリーポイント(これをベロシティという)を計算する必要がある。 過去3イテレーションの値の平均を「昨日の天気」として使うのが一般的だ。

チームができたばっかりであれば、チームのベロシティは低いだろう。ベロシティが低い状況下においては、チームはイテレーションの終了までにどれだけのストーリーを完了させられるか決めなければならない。

例えば直近3つのイテレーションの結果が6,8,10ストーリーポイント分達成していたとすれば、チームのベロシティは8ポイントとなる。従ってスケジュールはチームが8ストーリーポイントを完了すると想定して算出される。

10. ストーリーポイントは様々なチーム間で共通化できるのか?

異なるチームでは彼らがサイジングしたサンプルストーリーに基づいた異なる尺度のストーリーポイントを利用している。(訳注:相対的な指標なので、チーム同士でストーリーポイント1の意味が違うし、案件毎にも異なる) 同じシステムを作っているのでない限り、チームAの1ストーリーポイント完了の作業量とチームBの1ストーリーポイントあたりの作業量は異なる。そしてこの差は合計値であるベロシティにも現れる(従って同一案件でない限りベロシティの単純比較も意味がない)

大きいシステムをつくっていて複数のチームに分割している場合は、複数チーム間で見積もりのスケールをあわせる誘惑にかられるが、そうすることは本来のストーリーポイントの目的を失ってしまうことになりかねない。 (訳注:Scrum of Scrumで複数チームで構成する場合、バックログは原則的には1つであるべきで、そのバックログ項目自体に見積もりが必要。但しその数値をチームに持ち込むかどうか?という話かな?)

11. スパイク(技術的検証)ストーリーはどうやってポイントで見積もるのか?

スパイクストーリーとはチームが特定の機能を実装するに際してどうやったらより良い実装ができるか理解するために行う技術的検証である。またこれは概念実証にも使われる。 スパイクにおいてはどのくらいの作業が必要かはあまり分からないことが多いので、一般的にはタイムボックスを定める(時間で縛る)。そしてこれはベロシティの傾向をみることでおおよそのポイントに変換できる。 例えば、1週間の長さのスパイクを必要とし、チームのベロシティが16ポイントの場合、スパイクは8ポイントが割り当てられることになる。

12. 1ポイントあたりのコストを計算する方法はありますか?

1ポイントあたりのコストは一般的には イテレーションのコスト / イテレーションにおけるベロシティ で算出できる。

13. ストーリーポイントの見積もりは日数や時間で正確に見積もれないことに言い訳じゃないの?

言い訳ではなく、ユーザーストーリーを日数や時間で正確に見積もることは現実的にムダである。

さらには、日数や時間での見積もりはしばしばチームに対して想定した日数や時間でデリバリすることについてのプレッシャーをかけることになってしまい。間違ったコミットメントを達成するために燃え尽きてしまう結果になりかねない。これではチームが持続的なペースを維持することが出来ない

14. ストーリーポイントはビジネス価値と関連しているか?

ストーリーポイントはユーザーストーリーを実現するにあたっての内部的な指標である。従ってユーザーストーリーが生み出すビジネス価値については何ら反映しているものではない。 1ストーリーポイントのストーリーが同じシステムの4ストーリーポイントのストーリーよりもビジネス価値があるかもしれない。ビジネス価値を決めるのはプロダクトオーナーやステークホルダーが決定できるようにしておくのが良い。

15. チームがよりうまく見積もれるようになったことはどうやって分かるか?

チームが理想日で見積もっていれば、見積もりがよければトラッキングするのは簡単である。 しかしチームがデリバリについて圧力をかけられない程度に安全に見積もることは生産的とは言えないのである。 チームが相対的なポイントで見積もっていれば、似たようなサイズのストーリーは似たような時間で実装されることが傾向として現れてくる。もし悪い見積もりであれば、自動的に例外として悪い見積もりであることの証拠が現れるだろう。

 2011/04/10

サイト内検索


著作

寄稿

Latest post: