みなさんこんにちは。@ryuzeeです。
スプリント中に対象のプロダクトバックログ項目にどのように取り組んでいくか、というのは意外とよく質問を受けるので、ここで整理しておきたいと思います。 話を分かりやすくするために、スクラムボードを見ながら考えていきます。
アンチパターン1：プロダクトバックログ項目ごとに担当を決める
まず最初に避けるべきなのは、プロダクトバックログの項目単位で担当を決めてしまうやり方です。スクラムでは誰かが開発チームのメンバーに対して作業を割り当てることはしませんが、割り当てているかどうかに関係なく、開発チームのメンバーが「特定のプロダクトバックログ項目にサインアップして、そこを全部担当する」というのも避けるべきです。 このやり方をした場合には、次のような問題が発生します。
- 開発チームのメンバーは自分がサインアップしたプロダクトバックログ項目の完成ばかりを気にしてしまう
- 難易度の高いものや未経験のものをやりたがらない、という力が働いてしまうこともある
- すなわちチームの成果より個人の成果を重視する方向になりがち
- 全体で見たときに、スプリント終了時点で、「すべての項目があとすこしで終わる」という状態が頻繁に発生する可能性が高い
- スクラムでは未完成のものは、あと少しだろうがなんだろうが成果としては扱わない。すなわちその場合開発チームとしての成果が0になってしまう
- 個人の状況に左右されやすいため、スプリント単位での成果の量（ベロシティ）が安定しなくなる
- 従ってプロダクトオーナーからみた場合、将来の予測性が低く、計画がたてにくくなる
アンチパターン2：散発的に色々なプロダクトバックログ項目に手をつける
次に避けるべきなのは、色々なプロダクトバックログ項目に散発的に取り組んでしまうやり方です。 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない、といった場合に発生しがちです。このやり方をしてしまった場合の問題点は上記のアンチパターン1と同じで、「プロダクトバックログ項目が完成しない」リスクが高いことです。
また、このようなやり方をしている場合、潜在的に以下のような問題がある可能性もあります。
- 開発チーム内にスキルセットの偏りがあって、特定の人しか特定の作業ができない（が特定の人がいつも忙しい）
- 似たような作業は、同じタイミングで実施した方が効率がよい、という思い込みがあって、複数のプロダクトバックログ項目の作業をまとめてやってしまっている
- アーキテクチャ上の問題があって、複数の開発メンバーが同時に特定のコードを触りにくくなっている。コンフリクトが頻繁に発生して大変なので、それが起こりにくいところを着手してしまっている
アンチパターン3：プロダクトバックログの優先順位を無視して取り組んでしまう
絵は少々極端ですが、選択したプロダクトバックログの先頭から順番に着手するのではなく、順番を無視して着手しているのを見かけることもあります。 しかしこれはプロダクトオーナーに対する冒涜行為です。プロダクトオーナーが順番をつけるのは、その順番につくることで成果が最大になると考えたからです。もしこのやり方をして、スプリント終了時に上位の項目が完了しなかった場合、そのスプリントで本当に手に入れたかったものが手に入らないことになってしまいます。
このようなやり方をしている場合には、以下のような問題がある可能性があります。
- プロダクトバックログ項目間で依存関係があり、下位の項目が終わらないと上位の項目が終わらないようになっている
- プロダクトバックログのリファインメントが機能していない。事前に開発チームがその順番では作れない（作りにくい）ことをプロダクトオーナーに伝えられておらず、適切な並び順になっていない
じゃあどうするのか？
ここまで見てきて、もうどうすれば良いのか分かっていると思いますが、プロダクトバックログ項目にどう取り組んでいくか整理しておきましょう。
- 原則として、スプリントで着手するプロダクトバックログ項目は、上位の項目から着手する
- 幅広くいろいろなプロダクトバックログに着手するのではなく、上位の項目から「1つづつ」「全員でよってたかって」「完成させる」
- すなわちプロダクトバックログ項目の単位での同時仕掛りの数をなるべく少なくし、かつ完成までのリードタイムを短くする
- 完成させるためには、プロダクトオーナーの受け入れ確認が必要なので、項目が1つでも完成したら速やかに受け入れ確認を依頼する。すなわちバッチサイズを大きくしない
- 完成させることが何より重要なので、効率ばかりを追求しない
最後に
うちではこうやってる！というのがあればぜひ教えてください。