はじめに
Scrum Developers Night! Online #14に参加し、タイトルの議論をしました。勉強会運営の方でざっくりまとめていただいていますが、アジャイルプラクティスガイドブックでこの辺りは書かなかったなと思ったので、勉強会で話したことをまとめておきます。
安直にバックログアイテムを追加で取るのは反対
「バックログはいつも優先順位で並び替えられているのだから、手が空いたなら上から着手すればいいじゃない」と考えていた時期もありましたが、今は反対派です。 なぜなら「バックログアイテムをたくさん消化できることがよいこと」な雰囲気がチームで醸成されやすくなるからです。 たくさん開発し、たくさん機能をリリースして、それをチームで喜んでいると「自分たちは成果が出せている・プロダクトに貢献している」と感じさせてしまうでしょう。
また「スプリントレビューを通じた学びを踏まえてバックログの優先順位を見直すはず」です。 そこを考慮せず「バックログアイテムが上から順に着手されていれば大丈夫だ」とプロダクトオーナーが考えているのであれば、アジャイルではなくウォーターフォールなやりきり型の開発になっている気がします。
バックログアイテムを追加で取る選択肢そのものは否定しませんが、都度チームで考えて判断してもらうのが良いかと思います。プロダクトの状態・技術面の課題・開発環境の整備・スプリントゴールやプロダクトゴールの達成状況を鑑みて、バックログアイテムを追加で取ることが最適なのであればそれは良いと考えます。また以下のような作業も候補に入れておくと良いでしょう。
- ドキュメントの整備
- CI/CDの整備や改善
- いらない機能やコードを消す
- 今後取り入れたい技術の検証や勉強
- 次のスプリントでやりそうなことの事前調査
勉強会では「チームがやりたいことを別途用意しておき(バックログの下に積んでおく、バックログとは別にリストを用意するなど)、手が空いたら着手する」という話がありましたが、バックログが優先順位で並んでいない・関係者含めて議論できていないということでもあるので、これも良くないかなと考えています。
スプリントプランニングのやり方がおかしい?
予定していたよりも早く開発が進み、手が空くこと自体は確率的に起き得ます。 ただ頻繁に手が余るチームを見ていると「スプリントプランニングを真剣にやっていないのかな?」と思うところはあります。
スプリントプランニングではチームのベロシティを鑑みて、次のスプリントで対応できる分のバックログアイテムをバックログの上から順に取ります。進め方を議論したり、実装方針を確認したり、タスク分解を行うでしょう。皆さんのチームはこのタイミングで分解されたタスクを見直し「スプリント期間内に収まるか」を確認していますか? 収まらないなら計画を見直すか、取ったストーリーをバックログに戻す必要があります。逆に時間が十分に余りそうなら追加でバックログアイテムを取ることを検討してください。ベロシティやストーリーポイントはあくまでスプリントプランニングで取れる分量の目安なので、タスク分解や詳細な進め方がわかった段階で適切な分量だったか見直します。
スプリントプランニングは真剣にやりましょう。
スプリントゴールを達成できる率は50%くらいになるのが適切なのでは
「スプリントでできそうなことを毎回ギリギリまで攻めたなら達成率は50%になるはずだ」とRSGT2020の基調講演でジェームズ・コプリエンさんが話していました。「作業バッファを隠し持ち、毎回達成できるようにするのが良いことなのだ」という考えをチームが持ってないか、それが良いことなのかすり合わせることがこの問題の解決につながるのかもしれません。
