スクラムチームにとって、スプリントの終盤になって、取り組んできたストーリーがまだ終わっていないことに気づくことは、めずらしいことではない。おそらくそのストーリーは80%くらい終わっているように見えるだろう。そうしたストーリーはどうするべきで、そして進捗はどのように記録するべきなのだろうか？これらはあらゆるアジャイルチームが直面するであろう問題である。先ごろ投稿されたブログで(リンク)、David Starr氏は(リンク)自身の取り組み方を述べている。
進捗を記録する方法の一つは、現在のスプリントについて、そのストーリーの80%のポイントをチームに与えることである。一見すると、このアプローチは物事の状態を正確に反映しているように見える。そして、記録されるチームの速度が、スプリント間で上がったり下がったり変動しないようにするのに役立つだろう。またこの方法には、チームにとって、ある程度「満足する」価値がある。しかしながら、このアプローチには重大なリスクがある。このストーリーは検証可能な形ではなされておらず、「終わらせる」ために必要となる時間や作業の量は実際にはわからないのである。
次の候補としては、ストーリーをもっと小さなストーリーに分け、終わったとみなすことができるものについて評価をする方法がある。いくつかの、より小さなストーリーが本当に「終わった」という範囲で、この方法は「部分的な評価」のアプローチに付随するリスクを軽減することができる。この方法により、プロダクトオーナーは未完のストーリーの相対的重要度について、いくつかの決断をすることもできる。
David 氏は「部分的な評価」のアプローチは全て十分ではないと感じており、元のストーリーが完全に終了するまではチームに評価を与えないことを勧めている。彼はそのストーリーをもう一度見積もり、バックログに戻すことを推奨している。David氏は次のように言っている：「このモデルは物事をシンプルにし、チームが数字合わせのゲームをしないようにします。」
あなたのチームでは、部分的に終了したストーリーをどのように扱っているだろうか？コメントを投稿し、うまくいっているものは何か、そして上手くいっていないものは何かを教えて欲しい。
原文はこちらです：http://www.infoq.com/news/2008/09/Unfinished-Stories