BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース ユーザストーリー完了後の再見積は精度向上に有効か?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この記事に星をつける

おすすめ度
スタイル

BT