ユーザストーリー完了後の再見積は精度向上に有効か？

作者 Dan Puckett , 翻訳者 吉田 英人 投稿日 2010年9月28日

セクション

プロセス/プラクティス,

設計/アーキテクチャ

トピック

顧客要求 ,

コラボレーション ,

User Stories ,

チームワーク ,

Agile ,

見積もり

共有 |

原文(投稿日：2010/09/02)へのリンク

Scrum Development メールリストの最近のスレッドで，Paul　Battison 氏がひとつの質問を投げかけている。スプリントの終了後に完了したストーリーの再見積を行って，チームの速度 (Velocity) 評価に実際の成果を反映させることは適当だろうか，と問うものだ。

おおよその意見の一致として言うならば，完了したストーリーの再見積は行うべきではない。

どのような場面においても，完了したストーリーの再見積という作業に多くの価値を見出すことは難しい。Kelly Waters 氏がその理由を説明する。

速度という考え方は，見積のできの悪さを統計的に相殺するのに好都合です。例えば3ポイントと見積しながら実際には13ポイントになってしまったユーザストーリーに対しても，そのまま3ポイントとしてスコアしておきます。結果としてそれは，チームの速度がそのストーリーの見積時に考えていたよりも低かった，従って次回のスプリントの計画は，チームのより現実的な速度を基準として行われる，ということになるのです。

この調子でスプリントを重ねていくにより，通常は高すぎたり低すぎたりするチームの速度の評価値が，ストーリーの見積に適応するように自然に調整されていく。このように速度はそれ自体で正確になっていくため，意図的な事後調整は不要なのだ。

実際のところ，完了したストーリーに見積を合わせる作業は無意味であるだけでなく，かえって有害である可能性が高い。Paul Oldfiled 氏が次のように書いている。

[...]バックログを調整すると，現在の速度が信用できないものになります。この先いくつかのイテレーションの予想を正確にすることが，それほど重要でしょうか？ 速度の数値が信頼できるものに戻るには，長い時間を要するかも知れないのです。

ストーリーを見積る上でのポイントは，チームの速度を判断することだ。ところで「速度」とは何だろう？ Scrum Alliance の定義にれば，"

スクラムにおける「速度」とは，チームがひとつのスプリントで実行可能な未処理業務量である。

" 実後に行う見積調整は，スプリント実行前に作成したストーリーの見積と，スプリント完了後に作成したストーリーの "見積" との混同を引き起こし，結果的に今後のスプリントに対する速度予測能力を損なう。この２つのタイプの見積を比較し，理由付けすることは非常に難しい，というより事実上不可能なのだ。

では，完了したストーリーの再見積は行ってはならないことだろうか？ ほとんどの場合はそうだが，例外もある。Mike Cohn 氏によれば，

一般論として，元々の見積が完全に失敗していて，それがめったにないことだと分かっているならば，再度の見積をすることは有効でしょう。(要するに，見積が根本的に当たらないものなら，再見積などする意味もありません。) ２つめとして，相対的評価に変化があった場合は再見積をすべきでしょう。たとえば AJAX の学習が，チームが想像していた半分も難しくはない，と分かったような場合です。この新たな知識から，私たちの見積がAJAX を多用したストーリーに適さないことは明らかです。このことが，再見積を行う動機になるでしょう。

それでも通常は，完了したストーリーの見積は変えない，というのが最善の方法だ。後になって分かった事実をもとに見積を修正したい，という強い衝動はある。しかしほとんどの場合，そのような衝動には抵抗すべきなのだ。