バックログリファインメントの改善のために実験したこと
はじめに
会社のスクラムチームでスクラムマスターをしています。今のチームの目下の課題は、スプリントに投入するプロダクトバックログの準備が自転車操業気味で、ギリギリ確保できているか、若干足りないという状況が続いていました。
バックログリファインメントがうまくいっていないのではないか、という感覚がありました。問題と感じたことに対していくつか実験を実施し、うまくいったことがあったため、備忘としてまとめておきます。
課題と感じていたこと
以下を課題と感じていました。事実として観測したことには Fact、事実として観測していないことには Feel を付けています。
- Fact:プロダクトバックログのPBIのストックが、1スプリント分準備されていない
- Feel:リファインメント活動自体が活発ではなく、開発者が集まってリファインメントをしていない
- Fact:Readyの定義が現状と合っていない
課題と感じていたことと、それに対して実施したこと、やった結果起きたこと
Fact:プロダクトバックログのPBIのストックが、1スプリント分準備されていない。
考えたこと
なぜPBIの供給量が少ないのかという原因は、スクラムマスターの立場からは見えていませんでした。
推測としては、スクラムチーム外に承認フローが存在してそこがボトルネックになっているようには見えていて、まずプロダクトオーナーと課題と原因について会話する必要がありました。
やったこと
プロダクトオーナーと課題とその原因について会話した結果、原因としては以下の2つが上がりました。
- スクラムチームの外側でPBIの承認フローがあり、承認のタイミングが不明確
- PBIの供給量自体が少ない
それぞれの課題に以下の施策を設定しました。
- スクラムチームの外側でPBIの承認フローがあり、承認のタイミングが不明確
- スプリントのサイクルに合うように承認フローを再定義した
- ステークホルダー特定個人向けにスプリントレビューの推奨するふるまいを定義した
- PBIの供給量自体が少ない
- 過去の塩漬け要望のPBI化
やった結果起きたこと
PBIのストックが1〜2スプリント分に増加しました。
Feel:リファインメント活動自体が活発ではなく、開発者が集まってリファインメントをしていない（ように見える）
考えたこと
以下2点が、原因のように思われました。
- 開発者がリファインメントで何をすればよいのか、分かっていない。
- リファインメント対象のPBIに対する透明性の欠如。
やったこと
それぞれの原因に対して、実施したことは以下になります。
- 開発者がリファインメントで何をすればよいのか、分かっていない
開発者とスクラムマスターで、開発者リファインメントと称したリファインメントミーティングを実施しました。開発者リファインメントは以下の流れで実施しました。
1. プロダクトバックログでReadyではないPBIを優先度の高い順に5つくらい選択して記載内容を確認し、以下をリストアップする。
- Q&A事項
- 見積もるために必要なタスク
2. 開発者から見た改善事項をPBIにしてもらう
- 作成したPBIは、次のリファインメントでプロダクトオーナーに開発者から説明をしてもらい、実施する/実施しないをプロダクトオーナーに判断してもらう
- リファインメント対象のPBIに対する透明性の欠如
リファインメントの作業計画が曖昧なように思われたので、スプリントプランニングの際に、スプリント内でどのPBIをリファインメントの対象にするのかを話し合ってもらうようにしました。
1. スプリント期間内でReadyにする対象のPBIをプロダクトオーナーがリストアップする
2. PBIの状況をプロダクトオーナーに説明してもらう
3. 誰がまずPBIに対してアクションを起こす必要があるのかを議論してもらい、仕分けをする
- プロダクトオーナーがアクションを起こさないといけないPBI
- 開発者（デザイナー）がアクションを起こさないといけないPBI
- 開発者（エンジニア）がアクションを起こさないといけないPBI
やった結果起きたこと
原因と結果と次の課題は以下になります。
| 観点 | 結果 | 解釈・次の課題 |
|---|---|---|
| 開発者がリファインメントで何をすればよいのか、分かっていない | 開発者リファインメントで作成したPBIがいくつか採用された。ただし、優先順位が高く設定されて実際に開発に至るものは2〜3割で、プロダクトバックログのストック不足の根本解消には至らなかった。レトロスペクティブでは「良かった」というフィードバックが得られた。 | 開発者の理解や納得感は向上した一方で、自主的にリファインメントを継続する流れにはつながらなかった。 |
| リファインメント対象のPBIに対する透明性の欠如 | リファインメントの目的が明確になり、Readyにするために何をすべきかが可視化された。各自のアクションをデイリースクラムで共有するようになり、タスクの受け渡しがスムーズになった。 | 自律的なアクションのきっかけは作れたが、デイリースクラム以外の場での自発的な会話はまだ少ない。「公式な場＝安全な場」という認識が強い可能性があり、今後はデイリー以外で相談しやすい仕掛けが必要。 |
Fact:Readyの定義が現状と合っていない
スプリントプランニング、リファインメントでの開発者の発言に、Readyの定義を意識していなさそうな内容があり、指摘しました。
考えたこと
まず、Readyの定義の意義が、開発者とプロダクトオーナーにうまく伝わっていないように感じました。
scrum-guides にReadyの定義の意義について確認すると以下のような回答が返ります。
* 透明性の確保: プロダクトバックログアイテム（PBI）が「準備完了（Ready）」の状態であることは、スプリントプランニングにおいて選択可能であることを示し、チーム全体の共通理解（透明性）を高める役割を持ちます。
* プランニングの円滑化: 十分にリファインメント（洗練）され、詳細や見積りが明確なアイテムは、スプリント内で「完成」させる可能性が高まり、不確実性を低減します。
* 責任の明確化: 開発チームが自信を持ってスプリントに入れられる状態を定義することで、無理な計画を防ぎ、経験主義に基づく予測可能性を向上させます。
上記の「Readyの定義の存在意義」を開発者とプロダクトオーナーに説明した後に、以下の選択肢を提示することにしました。
1. Readyの定義を変えずに、うまくいく仕組みづくりをする
- これはReadyの定義を満たすようにリファインメントをうまく進めてもらうということを意味しています。
2. PBIを分割して、デザイン成果物の組み込みを分ける
3. Readyの定義を変更する
- PBIのデザイン修正の見通しが立っているのであれば、Readyとする運用。
- デザイン成果物の完成をPBIのReadyの定義に加えていたが、それが足枷となって、PBIがReadyになっていなかったように見えた
- デザイン成果物の完成ではなく、完成の見込みが立った状態をReadyとするのが良さそうに見えた。
やったこと
選択肢から選んでもらった結果 Readyの定義を変更する となり、チームでReadyの定義を変える方向の合意が取れたので、変更することにしました。
やった結果起きたこと
どちらかというと、施策そのものよりも過程でのReadyの定義の説明の方が効いた気がしていて、開発者がReadyの定義を意識するようになりました。Readyの定義を変えることの効果検証は変えたばかりなのでできていません。レトロスペクティブで以下の点を確認してみようと思います。
-
スプリントプランニングの時間と納得感（検査の効率）
Readyの定義を緩めているので、スプリントプランニングの時間が長くなる可能性があります。
そのあたりでどのような影響が出たのかを確認したいと思います。 -
ベロシティの安定性（予測可能性）
ベロシティが不安定になる可能性があります。ベロシティにどのような影響があったのかを確認したいと思います。
実験をしてみての感想
リファインメント改善のためにいくつか実験をしてみましたが、その感想になります。
-
スクラムチームにいる人、取り巻く組織の状態、開発エコシステムによって、課題の種類や同じ課題でも解消の仕方が変わってくる。 前職時代のスクラムチームとは環境変数が違います。環境変数が違えば表出する課題も変わってくるというのを学びました。 目指す状態は変わらない気がしますが、その解消の仕方も状況の変化で変わってきます。とっている対策は違いますが、前職での経験は活かせているなとは思います。
-
受発注混合チームにおいて開発者とプロダクトオーナーにうまく協働してもらうのは難しい 現在のチームはプロダクトオーナー、デザイナー、スクラムマスターが社内、エンジニアが開発パートナーという受発注混合チームです。
今のところ試したリファインメント改善の実験はうまく機能しましたが、契約上の問題、組織構造上の問題に将来的にぶつかるかもしれないという懸念はあります。ただ、そのような問題も、まずはリファインメント対象のPBIに対する透明性を高めることが、解決の糸口になりそうな気はしています。
以上です。 今後ストックが溜まってきたらまたまとめてみたいと思います。