概要
社内でスクラムチームを組んで、スプリントを回しています。
チームメンバはスクラムの基礎知識を持っており、スクラムイベントにも慣れています。私は開発者と兼任のスクラムマスターです。
プロジェクトも終わりが見えてきた頃のスプリントプランニングで、次のような発言がありました。
「あとは残りのプロダクトバックログアイテムを消化してバグを修正して、最終期限に間に合うようにリリースするだけだから、いちいちスプリントゴールを考える必要はないんじゃない？」
それに対して私は、スクラムの考え方に基づいて「スプリントゴールは絶対必要！」と主張しました。その際に、チームメンバーと「なぜスプリントゴールが必要か」を話し合い、合意を得ました。端的に言えば、スクラムの三本柱とイベントを効果的に行うためには必須だと思ったからです。
その際に改めて、「具体的にどうして必要なの？」「スプリントゴールは何の役に立つの？」というのを整理したので以下にまとめました。
他のイベントの話をするとまとまりがなくなるので、本記事ではスプリントゴールにフォーカスして進めます。
詳細
スクラムの三本柱
スクラムでは「透明性」「検査」「適応」の三本柱が重要です。
詳細はスクラムガイドに記載があるのですが、ざっくり言うと「あるものに対して、内容が誰でもわかるようになっていて（透明性）、変化を見逃さないようになっていて（検査）、目的に沿う形に軌道修正できるようになっている（適用）」状態を維持することだと理解しています。
スプリントゴールがないとどうなる？
スクラムの三本柱を、十分に機能させることができません。
言い換えれば、そのチームのスクラムイベントは十分な価値を生み出せなくなります。
たとえば、スプリントゴールがない場合のチームの動きを考えてみます。
日々のデイリースクラムや開発において、「何のための作業をしているのか」を照らし合わせる到達目標がありません。このため、「透明性」を担保できなくなります。
また、スプリント中に新たな作業が見つかった場合、「何から手を付ければよいか」「それはいま本当にすべきことか」を判断することができません。
プロダクトゴールは必要な作業を教えてくれるかもしれませんが、プロダクトバックログアイテムの優先順位を決めるには不十分です。これは、「検査」と「適応」ができない状態であることを示しています。
やり方はチームに依る
スクラムのイベントはチームによって進め方が変わることがあると理解します。
ただ、あくまでもスプリントゴールは必ず設定し、その内容が適切でないと感じるなら、次のスプリントで改善する、という形が良いと考えます。
では、どんなスプリントゴールを立てればいいのか？ という疑問も出てきます。
「今回のスプリントでやると決めたスプリントバックログアイテムを全て消化する」というのは、スプリントゴールにはなりません。いわゆるハリボテのスプリントゴールです。
スプリントゴールの決め方
2020年度版のスクラムガイドでは、スプリントゴールに明確な説明が追加されているので、そちらを引用します。
確約（コミットメント）：スプリントゴール
スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
スプリントゴールは、トップダウン的に考えれば、プロダクトオーナーと交渉して決めた今回のスプリントのスコープを表現するものです。
あるいはボトムアップ的に考えれば、今回のスプリントのインクリメントによってユーザが得られる価値を表現するものです。
そして、その達成を開発者は確約します。達成できない見込みが出た場合、スプリントの中止も視野に入れるほどの、とても重要なものです。
現在の私たちのチームでは、実はほとんどプロダクトオーナーが機能しておらず、開発者がその役割を担っています。
そのため、ボトムアップ的にスプリントゴールを決めることが多いです。
プロダクトオーナーからの要望はありませんが、エンドユーザはレビューに参加してくれるので、スプリントゴールは「エンドユーザが価値を実感できる形」になるように決めています。
インクリメントを作ることだけを重視すると、ともすれば「スプリントバックログアイテムをたくさん消化すること」が目標になってしまいます。
そうではなくて、「今回のインクリメントでユーザに与えられる価値は何か」をスプリントプランニングで意識することで、チーム活動の「透明性」を担保し、ゴールが達成できるかを「検査」し、必要があれば「適応」することができると思います。
余談：私のチームの話
社内でスクラムチームを組んで、スプリントを回しています。
私は開発者と兼任のスクラムマスターです。スクラムマスターとして、チームが良い感じにスクラムを実践できるように、縁の下の力持ちをしたいと思って頑張っています。
チームメンバはスクラムの基礎知識を持っており、スクラムイベントにも慣れています。
そんなチームでも、「スクラムのルールではこうだけれど、いまのチームの状態には即していないから変えよう」ということが起こります。チームメンバが全員納得してそれを行うなら、チームの課題解決の一つとして良いことだと思います。
プロジェクトも終わりが見えてきた頃のスプリントプランニングで、次のような発言があり、私は正直驚きました。
「あとは残りのプロダクトバックログアイテムを消化してバグを修正して、最終期限に間に合うようにリリースするだけだから、いちいちスプリントゴールを考える必要はないんじゃない？」
それに対して私は、スクラムの考え方に基づいて「スプリントゴールは絶対必要！」と主張しました。その際に、チームメンバーと「なぜスプリントゴールが必要か」を話し合い、合意を得ました。端的に言えば、スクラムの三本柱とイベントを効果的に行うためには必須だと思ったからです。
その後、スプリントゴールは設定され、現在のスプリントでもスプリントゴールの設定は継続しています。
いろいろな考え方があり、やり方もチームによってさまざまだと理解します。
その中で私は、「スプリントゴールを作らない」以外の方法で、スクラム活動の改善が実現できると信じます。
参考
- スクラムガイド 2020年度版(日本語)
- AGILE STUDIO:スプリントゴール
- スクラムの資格はリンク先をご参照ください（詳細割愛）