スクラムで開発チームが自由な取り組みをするには？

みなさんこんにちは。@ryuzeeです。

スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。それに対して、どのように対処していくべきか考えてみましょう。考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています）

複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）
スプリントとスプリントの間に休憩を入れる（✕）
フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）
スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）

それぞれを順番に見ていきましょう。

複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）

まずは基本知識のおさらいをしましょう。スクラムでは、プロダクトオーナーは限られた期間とリソースを活用してプロダクトの価値を最大化しようとします。そのためにプロダクトバックログの並べ替えの最終決定権限を持っています。並び順はスプリント開始前には最新になっている必要があります。一方でプロダクトバックログアイテムすべてを作成する義務があるわけではなく、開発チームが自分たちに必要な項目を作成することもあります。

例えば1週間スプリントを3回実施したら、1回は開発チームが好きなことをする、とした場合には次のようなことが問題になります。

この1週間の中断のときだけ、プロダクトバックログの先頭にある項目をデリバリーするリードタイムが倍になる。すなわちプロダクトオーナーはスケジュール見通しの予測が難しくなる
前のスプリントの最後に行ったレトロスペクティブの結果を、すぐにプロセスに反映できなくなる
上記2つはいずれもリズムの悪さと言い換えられる。リズムが悪いと改善できているかどうかの比較もしにくくなる
もし1週間の中断で好きなことをやるといって、そのプロダクトで後回しにしていたこと（リファクタリングやツールの導入など）をやるのであれば、プロダクトに関する変更が入ることになるが、その一方でどんな順番で何をやっているのかの透明性が低くなってしまう

ということで、このやり方は避けておくのが良いでしょう。

スプリントとスプリントの間に休憩を入れる（✕）

スクラムではスプリントレビューとレトロスペクティブが終わればスプリントが終了し、次のスプリントはスプリントプランニングから始まります。すなわち、ここで検討するのは、スプリント終了から次のスプリント開始までにインターバルを取る、という考え方です。

結論としては、このインターバルが完全に空白の1日以上になるのは避けた方が良いでしょう。当日スプリントが完了して、翌日スプリントを開始するまでの間が休憩になる、という程度であれば許容範囲だと思います。

この休憩でも、前述のとおり、プロダクトの変更は避けて透明性の担保が必要です。でないと、そのうち実は分かっていたバグとか実はまずい問題のようなものをその時間を使って直すようになります。そして実はそれはスプリントでは完了していないことを誤魔化している状態であるとも言えます。

フィーチャー開発以外の取り組みを重点的に行うスプリントを必要に応じて用意する（△）

開発チームとしてやりたいことが色々あるのであれば、プロダクトバックログアイテムを作ってプロダクトオーナーに優先順位をあげてもらうように提案しましょう。そして、プロダクトオーナーがそれらのプロダクトバックログアイテムを中心に選べば、結果的にそのようなスプリントになります。

ここで気をつけるべきなのは（しつこいですが）、スプリントでどんなプロダクトバックログに取り組みたいかは、プロダクトオーナーの最終判断になるという点です。したがって開発チームが望んだとしても、ビジネス上の判断で、フィーチャーを優先するケースはあり得ます。また、プロダクトオーナーが、フィーチャー開発以外の作業の重要性を理解しておらず、そのようなプロダクトバックログアイテムをやりたがらないことも考えられます。プロダクトオーナーがフィーチャー以外を軽視しているような場合は、開発チームはプロダクトオーナーに対して十分な説明をした上で、それでもダメならスクラムマスターが間を取り持つと良いでしょう。

スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）

最後はスプリントのキャパシティの見直しです。常に開発チームが追われているように感じるのは、スプリントでやらなければいけないことがたくさんありすぎるからです。すなわち、やることが多いので、本当は大事な活動を犠牲にしてしまっている可能性があることを意味します。このような場合、開発チームが1スプリントで、実際に開発作業に使えるキャパシティを見直したり、それにあわせてスプリントに投入するプロダクトバックログの量をコントロールすると良いでしょう。開発チームにプレッシャーをかけても速くなりません。すなわちベロシティの向上を常に求めるような環境はおかしいということです。