あなたのチームで、いくつかもしくは全てのストーリにおいて“定義した完了”に失敗し続けているとしたら、あなたのチームには何が起きているのだろうか。スプリントの境界を拡張すべきか？プロダクトオーナーはこの状況をどのようにして乗り切るべきだろうか？このケースはチームが４週間のスプリントを使っているチームで、あるチームのメンバーがチームに対して言及したものである。
Victor Hugo de Oliveira氏は、スクラムの基礎であるスプリントの目的は、チームが助け合う事にあると説明し、期間を伸ばすべきでないと述べた。“時間切れはスプリントの終了だ。”彼はチームはストーリーの完了に注力する事も提案した。(すなわち 「完了, 完了」だ。) たとえ最初にそのスプリントで彼らがコミットした90%のストーリであったとしてもだ。
Jussi Mononen氏は、ストーリーが一つのスプリントで完了せずに次のスプリントにあふれるのは、プロダクトオーナの考え次第だと述べた。Angel Lopez氏は あるケースについて言及した。
あるケース: 期限の決められたプロジェクトで、機能の実装コストを"間違って見積もりました。"そして次のスプリントの開始では、プロダクトオーナーにとってより重要なストーリーは、次のストーリーなのでその機能を忘れた事にしました。そしてその機能を除いた現在のストーリーは、彼から検収されました。
Adam Sroka氏は,チームにスプリントが終わる事ができないなら、次のストーリを始めないようコーチし、そして一度に全てのストーリを始めない事でスプリントの間、プロダクトオーナによる優先度の変更をより自由に行える。
Jussi氏もこれはチームがスプリントとリリース共に、期待される全ての機能を提供できないならばなるだけ早く話し合うべきで、これはチームがコミットし過ぎである事を示していると述べた。
Roy Morien氏は2点を強調する
- スプリントの長さを２週間にする: “２週間はスプリントの長さの下限だ。したがって、多少は確実な計画をより簡単にでき,進捗のデモを見せる機会をより多く与える。とはいえ、これを裏付ける統計はない。この短い期間がよりスプリントをコントロールできるようにし、終わらない仕事を減らし、スプリントの間より高い精度の見積もれ、コミットメントと緊急の課題の判断を正しくさせ、そしてチームの環境と心理的な側面の全てをよくするだろう。”
- ほとんど完了しているとは、まだテストしていないストーリーのコンポーネントのことで、ストーリーとして求めていたものかわからず、問題が隠れているかもしれないため、プロジェクトを沈没させるかもしれないということだ。
またチームがなぜFitNesseやRobotFranework、そしてCucumberなど受け入れテストを書くためのツールを使わないのか尋ねた。