スプリントが終わる前の日に、重要なストーリーに問題が見つかってそのストーリーが完了できないことがわかったとする。こんなときはどうするべきだろう。そのストーリーをバックログに戻すか、それともスプリントを延長するか。Pablo Emanuel氏は、この場合はストーリーをバックログに戻してもいいし、スプリントをキャンセルしてもいい、と言う。続けて氏は、スプリントを遅延させるのはは反復開発の原則を侵すことだ、と指摘している。
反復開発の背後には、可能な限り定期的にプロセスをフィードバックする、という考え方があります。 特にはじめのうちは、1つのイテレーションを延ばしたくなるかもしれません。しかし、ジムではしたいことをしている人よりも個人トレーナーと一緒に決まったスケジュールで運動する人が多い、というのと同じ原則に基づいて考えれば、イテレーションを延ばすべきではありません。
加えて氏は、イテレーションのデモは見るべき点が少ないときでも重要だ、と指摘している。デモをすれば最新のイテレーション計画をレビューする機会を得られるからだ。
Maurice le Rutte氏は、次のように述べている。“見つけた欠点が原因で項目を完成できないということを許せば、チームの信頼性は上がり、より信頼されるようになります。しかし一方で、デモが遅れてしまうと完全に違うメッセージを送ってしまいます。つまり、プロセスをコントロールできていない、他のことでも遅れるだろう、というようなメッセージです”。氏は続けて、顧客が見つける前に問題を見つけてくれたチームに感謝すること、そして、振り返りを行ってストーリーに何がおこったのかはっきりさせることの重要性を指摘している。
Dan Rawsthorne氏はレビューや振り返りがプロダクトオーナにもたらすのは、次のスプリントでの優先順位を変更することだ、と指摘している。こうすることで問題のあるストーリーをスプリントに含めなくすることができるかもしれない。
スクラムの最後になって問題点が見つかってしまう状況の中で、スクラムマスタが行う定期的な指導を通じて、スクラムマスタが計画に問題があると考えていることに気付くチームもある。Cenk Çivici氏はなぜストーリーがうまくいかないのか尋ねている。“ストーリーが大きすぎないでしょうか。受け入れの基準は明確でしょうか。十分な時間をかけてテストをしているでしょうか。ストーリーを終わらせるのにテスト担当者の数は十分ですか。”
Juan Banda氏はINVESTという頭字語を思い起こさせてくれた。優れたユーザストーリーは独立していて(Independent)、交渉の余地があり(Negotiable)、価値があって(Valuable)、見積もり可能で(Estimatable)、小さく(Small)、テスト可能(Testable)である。そして、氏はこの中で「小さく」の部分がないがしろにされていないかどうか、という点を指摘している。
Inanc Gumus氏 は、チームに必要なのは(プロダクトオーナとスクラムマスタ以外で)3人だけで、はじめに、3日で完了できるようにストーリーを見積もってしまうことを説明した。 例えば、"広告主は、予算がつきたらすぐに広告を取り下げてほしい。"というようなストーリーだ。このチームの考えでは、ストーリーも最も小さく切り出すとこの大きさになる。
Paul Hudson氏 は、後になって大きなストーリーと接続できる小さなストーリーを提案した。例えば、“広告主はいつでも広告を止められるようにしたい。いつでも、広告費がどれくらいなのかわかるようにしたい”。Ron Jeffries氏の方法は少し違う。 “はじめのストーリーは次のように分割できます。"予算がなくなった広告活動が与えられたら、それは実行しない"。ここから2つの作業が導きだせます。つまり、1つのif文と、予算がなくなった広告活動を表すビジネスロジックを作ることです。これに半日以上かかるのなら、その理由が知りたいです。”
Mark Levison氏は筆者のことだが、Gumus氏がRoot Cause Analysisや他のツールを使ってチームに振り返りを求めていることについては議論の余地がある、と考えている。しかし、すでに氏らはなんらかの答えを出しているのかもしれない。
両者の考えのコンセンサスは次のようになるだろう。問題が発見されたらすぐにプロダクトオーナへ報告する。実装された機能のデモを行う。プロダクトオーナが優先順位の変更をできるようにする。問題の原因を特定するために振り返りを行う。スプリントは延長しない。