はじめに
まいど、ツクリンクでエンジニアをしているあかまつです。
3日目の記事の熱狂冷めやらぬうちの再登場です。
プロダクトバックログリファインメント（以下、リファインメント）はスクラムチーム、ステークホルダーが一同に介し、プロダクトバックログアイテムが持つユーザーストーリーやゴール、更には開発メンバーが実装を行う際に参考にする要件や仕様を全員で話し明確にする役割を持っています。
しかしながら、このリファインメントをなかなかうまく活用できないこともあると思います。
今回は私が所属するチームが実践（実験）してみたリファインメントについて書いてみようと思います。
ちょっとした課題
ツクリンクのWebアプリケーションチームは複数あり、LeSS（Large-Scale Scrum）というアジャイルフレームワームを導入した開発を行っています。
このLeSSでもリファインメントはもちろん存在するのですが、参加する関係者が多いことや各参加者の時間的な制約から優先順位や担当チームの確定と大まかな概要の説明に留まり、仕様などの詳細な部分を詰め切れないまま終わってしまうことがありました。
このため、各チームが独立して行うスプリントプランニング（以下、プランニング）時や、それより後のタスク着手後に要件や仕様の確認が必要になることがあります。
しかしながらステークホルダーも忙しく、なかなかスケジュールが合わずで気付いた時にはスプリント開始から数日が経過していた、なんてこともしばしば。
結果的にスプリントのベロシティが安定しない状況が続くことがあり、心理的にもあまりよろしくなさそうだったので改善してみることにしました。
小さなリファインメント
取り急ぎ問題になっていたのはプランニング時やタスク着手後に要件や仕様の確認が発生し実装の手が止まってしまうことでした。
プランニング時に要件や仕様が（ある程度）クリアになっていれば実装は進められるはずなので、以下のようなルールで開発メンバーだけでリファインメントをするようにしてみました。
- 開催は毎週1回、大体1〜2時間程度
- 自チーム担当が確定しているタスクが対象
- 開発メンバーだけで仕様や実装方法を書き出す
- 不明点などあればコメントなどの非同期コミュケーションでステークホルダーに質問
- 急いでいる場合は例外的に同期コミュニケーション
本来であれば元々のリファインメントでここまでできるようにすることが理想なのですが、前述したように参加者が多いことによる時間的な制約からそこをテコ入れするのはなかなかハードルが高いと思い、このような小規模なリファインメントを別途設けることにしました。
試してみた結果
このようにして、プランニング時には既に仕様や実装内容がクリアになっているアイテムのみをスプリントに投入できるような状況を作るようにしてみました。
結果的にこの改善はうまくいきまして、スプリントに投入するアイテムは常に内容が充実した状態になり、プランニングで追加の確認が必要になることは激減しました。
また、リファインメントの時間を別途設けたことによってメンバー全員でじっくりと時間をかけて仕様や実装方法について話すことができるようになり、これまでたまに起きていたメンバー間での認識の齟齬や仕様の誤解も減らすことができました。
今改めて振り返ってみましたがこの小さなリファインメント導入にデメリットは見当たらないので、今後も継続していきたいと思います。
さいごに
いかがでしたでしょうか。
スクラムは組織やチームの環境によってその運用方法を柔軟に変えていくことが重要なので、今回実践した内容がそのまま参考になるかはわかりません。
しかしながら、リファインメントをうまく活用できていないと感じている方は、このような小さなリファインメントを導入してみるのも一つの手かもしれません。
もしみなさんも「こういうことをしてスクラムを改善できたよ！」みたいな事例があれば教えていただけると嬉しいです！
ほなまた、おおきにー。
Discussion