【スクラム】スプリントゴール🚩は思い切って1つに絞るのが良いと感じた話
私の所属する企業では、スクラムを採用しています。
私のチームも、漏れなくスクラムを使っており、なんだかんだ3年ほどスクラムに基づいて仕事をしています。
最近、「スプリントゴールは思い切って絞るのが大事だな」と感じることがあったので、そのことについて書きます。
自チームのスクラムへの問題意識
スクラムにそれなりに手応えを感じつつも、ちょっとマンネリ化しているような問題意識がありました。
そんな時、「なんちゃってスクラム」に気づくためのコツという記事を読んで、
「うっ、私のチーム(というか自分)、スプリントゴールの達成意欲が弱いかも...」
と問題意識を持ち始めました。
実際、スプリントゴールと言いつつ、
- タスクA
- タスクB
- タスクC
- タスクD
とTODOが並んでいるだけのゴールになってしまっている時もありました。
スプリントゴールが曖昧だったこともあり、「チームでスプリントゴールを達成しよう！」という熱量も高くなかったように思います。
スプリント期間が1週間になる
ちょうど1つのプロジェクトがひと段落し、新しいプロジェクトがスタートしました。走り始めということもあり、スプリント期間が2週間から1週間に変更になりました。
2週間に慣れた身からすると、1週間スプリントは短いです。祝日や有給が入ると、開発に割ける時間は1スプリントで2日営業日のみなんてこともあり得ます。
となると、当然スプリントゴールを厳選せざるを得ません。
「このSprintはこれしかできないね」
ということで、スプリントゴールを明確に1つだけに限定しました。
これが結果として、次のような良い効果をもたらしたと感じています。
スプリントゴールを厳選する効用
1: チームでの協力が発生しやすい
スクラムガイドには
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。
と書いてあります。
スクラムチームはスプリントゴールを達成するために、協力し合うことが求められているということです。
ところが、スプリントゴールが曖昧だったり、複数に分散していると、
- 🧑Aさんは、❤️❤️の機能
- 👩🦰Bさんは、⭐︎⭐︎のテスト
- 🧑🦱Cさんは、🔵🔵のUI改善
など、同じチームなのにまったく別のタスクに取り組む状況が生まれます。
このような状態では、チーム内での協力は生まれにくいです。
自分の持っているタスクに責任を持って取り組んでいるからこそ、「協力やレビューもしたいけど、ここで時間を使ってしまうと自分のタスクが終わらない...」というジレンマに陥ります。私のチームはまさにこのような状況に陥っていました。
でも、スプリントゴールが厳選されていれば、各開発者が取り組むタスクはそのゴールを達成するためのものになります。ゴールが統一されていると、当然助け合いも発生しやすいです。
例えば、「Bさんのやっているタスクの方が優先度が高そうだし、今日は自分のタスクを一旦止めて協力したほうがスプリントゴールを達成できそうだな」のような判断がしやすくなります。
スクラムチーム内の助け合いが生まれない時は
- 「スプリントゴールが曖昧なのでは？」
- 「スプリントゴールが絞り切れておらず、各メンバーが別の領域の仕事をしているのでは？」
と疑ってみるのが良さそうです。
決して、「うちのチームは周りを助けるマインドを持った人がいない...」なんて、個人の気質のせいにしてはいけないですね。きっと、多くの場合は仕組みの問題だと私は思います。
2: コンテキストが共有されているため仕事のスピードが上がる
チームメンバーが同じタイミングで同じゴールに向けて仕事をすると、コミュニケーションコストが劇的に下がります。
全く別種のタスクに取り組んでいると、それぞれコンテキストが異なるので、
- 業務仕様の確認
- 使っているAPIの仕様確認
など、前提情報を共有する必要があったり、必要なコミュニケーションが増えます。
一方で、スプリントゴールが1つだと、
- 🧑Aさんは、❤️❤️の機能
- 👩🦰Bさんは、❤️❤️のテスト
- 🧑🦱Cさんは、❤️❤️のUI改善
など、取り組むタスクは違えど、コンテキストは同じです。お互いに前提情報を理解できているので、情報伝達的なやり取りが減ります。その時間をもっとプロダクトを良くするために使えるようにもなります。
個人的には、スプリントゴールを厳選したことで、格段にコードレビューしやすくなって助かっています。
自分が❤️❤️の機能に取り組んでいるときに、全く別の⭐︎⭐︎のレビューをするのは非常に時間が掛かります。コンテキストが異なる場合、「このコードは何をしようとしているのか？(What)」「この人は何のためにこの変更をしたのか？(Why)」から理解する必要があるからです。こういうプルリクエストのレビューは骨が折れます。
もちろん、プルリクエストに前提情報は書いてあることもありますが、そのような情報が抜けている場合もあります。そんな時は実装した人に質問するやり取りも発生します。
一方、スプリントゴールが統一されていると、何を(What)何のために(Why)の部分は理解できています。自分も同じゴールに向けて仕事をしているのですから当然です。
あとはどうやるか(how)の部分を確認すればよく、効率よくレビューができます。
最後に
以上、スプリントゴールを厳選したら、「なんか良い感じで開発が進んだ気がする😄」という話でした。
とはいえ、割り込みのタスクや保守運用フェーズシステムのタスクが発生するなど、スプリントゴールだけに集中できているわけではありません。
よりチームとしてゴールを共有して価値が出せるよう、引き続き色々トライしていきたいです。
Discussion