スクラムガイドから読み取る「スプリントの中止」

アジャイルグループの石田です。今回は、中々話題にあがりにくい「スプリントの中止」に関する話題です。

開発のリズムを大切にするスクラムの中で、そのリズムの要となるスプリントを途中で辞めるのはもちろん可能な限り避けたいものです。スクラムガイド2017では、「スプリントの中止がチームのトラウマになってしまうこともある」とさえ言っています。

とはいえ、やむを得ない事情というのはどんなプロジェクトにもあるもので、そういう時のことを事前に考えておくことも大切なことです。

タイトルの通り、まずはスクラムガイドにスプリントの中止についてどのように記載されているか確認してみましょう。2020年度版スクラムガイドの内容は下記の通りです。

スプリントゴールがもはや役に⽴たなくなった場合、スプリントは中⽌されることになるだろう。プロダクトオーナーだけがスプリントを中⽌する権限を持つ。

記載はこれだけです。あまりにも簡潔に書かれていて、よく分かりませんね。「スプリントがもはや役に立たなくなった場合」がどういう場合なのか、考察が必要そうです。

こういう時はひとつ遡って、2017年度版のスクラムガイドを確認してみましょう。こちらでは、スプリントのサブ項目として「スプリントの中止」が用意されており、もう少し詳細に書かれています。その前半部分のみの引用です。

スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダクトオーナーだけである。このときに、ステークホルダー・開発チーム・スクラムマスターの意見を参考にすることもできる。

スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくなったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したからといって影響があることはほとんどない。

では、スクラムガイド2020に書いてある「スプリントがもはや役に立たなくなった」というのは、どういう時が考えられるでしょうか。いくつか考えてみます。

ひとつ目は、会社の方針転換や市場の変化によりそのゴールを目指すこと自体に意味がなくなった、作る必要がなくなった場合です。スクラムガイド2017では、これを「スプリントゴールが古くなってしまう」と表現しています。
例えば自社新製品の販売のためにECサイトの改修をしていたが、その製品の販売自体が中止になってしまった、といったときです。

これはまさにスクラムガイドに書いてある例そのものですので、スプリント中止の対象となるでしょう。

しかし、もしそのためにウォーターフォールを用いて何ヶ月もかけた開発を行なっていて、リリース直前で開発中止になったとすればその影響・損失は甚大ですが、1〜2週間のスプリント範囲での開発中止であればその影響は少なくて済みます。アジャイル開発の恩恵を受けた中止の判断と言えます。

次に、差し込み案件や緊急のバグ対応によりスプリントゴールを目指している場合ではなくなった、といったような時です。実際のプロジェクトで最も起こりうる事象でしょう。

スクラムガイドを素直に解釈すると、これが「スプリントゴールがもはや役に立たなくなった」と言うには少し違う気がしますが、現実的に中止せざるを得ない状態になった、ということだと思います。その差し込まれた案件が、今すぐチーム・プロジェクト総出で対応しなければならないとプロダクトオーナーが判断したのであれば、中止の要件に当てまるものと考えられます。

ここで重要なのは、スクラムガイドにも書いてあるようにこの中止をする権限はプロダクトオーナーのみにある、ということです。
開発者が今回は差し込みの作業が入ったのでスプリントを中止にしましょうと勝手に決めることはできませんし、ステークホルダーがプロダクトオーナーを飛び越えて中止を言い渡すことももちろんできません。
プロダクトオーナーがその差し込み案件の重要度、ボリュームを見極め、今すぐスプリントを中止してでもスクラムチーム総出で対応すべきなのか、あるいは中止とまではいかずとも一部スプリントゴールを変更して対応するのか、判断をする必要があります。

また、もしそのような差し込み案件やバグ対応が頻発し何度もスプリント中止を余儀なくされるようなことがあれば、それはスクラム自体がうまく機能していない可能性が高いため、スクラムマスターが動いてステークホルダーに働きかけるといった対応が必要となります。

最後は、メンバーの大半がインフルエンザにかかってしまい、スプリントゴールの達成が難しくなったような場合です。

この場合はスプリントゴールそのものが役に立たなくなったとは言えず、チームのコンディション的に今回全て終わらせるのは難しい、という状態です。

そうなるとスプリントゴールは未達となってしまいますが、できる範囲の開発を続けることになるでしょう。メンバーが復帰したら改めて次のスプリントゴールを決め、正常なスクラムチームの状態を取り戻していきます。

スプリントの中止はスクラムチームにとって出来る限り避けたいものです。しかし、予定通りにいかないのがプロジェクトです。

スプリントの中止の判断を迫られた時にプロダクトオーナーがそれをコントロールし判断できるのか、またスプリントの中止が頻発する場合、スクラムマスターがどういうアクションを取るのか、今一度考えてみましょう。