※この記事はAgileStudioに掲載した記事の転載です。
元記事：「何すればいいんでしたっけ」から始まるリファインメントを、前日の準備で立て直したチームの試行錯誤（トナリノ）
「何すればいいんでしたっけ」
あるチームのリファインメントは、この確認から始まるのが常でした。
今回ご紹介するのは、リファインメント（バックログアイテムをReady＝開発着手可能な状態にしていく場）を、PO（プロダクトオーナー）主導ではなく開発メンバーだけで実施しているチームです。
リファインメントが行き当たりばったりになると、その後のスプリントプランニングで要件の確認に追われます。この記事は、それを止めるために、リファインメントの前日に準備の時間を置いたチームの試行錯誤の記録です。
トナリノは、隣のチームの泥臭い試行錯誤をそのまま届けるコミュニティです。
様々なチームの「うまくいかなかったこと」「試してみたこと」「今の現在地」を記録しています。正解やTipsではなく、あるチームのリアルな試行錯誤をお届けします。
リファインメントは、開発メンバーだけでやっている
このチームのリファインメントには、POが入りません。最初からこの形だったわけではありません。
元々予定していたのは、リファインメントでPO主導でストーリーをReady状態にし、その後のプランニングで計画を立てる、というサイクルでした。
うまくいかなかったのは、POが100%一緒にいられるわけではないところです。このチームのスプリントは1週間です。その短いサイクルの中で、「次」や「次の次」のスプリントで着手するであろうストーリーをスピーディにReady状態にすることが、難しかったのです。
時間切れが当たり前だったリファインメントと、4時間かかるプランニング
以前は、リファインメントの時間がこう過ぎていきました。
まず「何すればいいんでしたっけ」から始まる。現状を確認してみる。対象のストーリーが分かっても、中身がまとまっていないので、今度はストーリーの現状を確認する。やっと何の話を進めればいいか分かって話し始めるときには、ほとんど時間が残っていない。そして時間切れ。
ふわっとしたところが多いまま、いきなり全員で向き合う。気になる点が各自から出て、発言が発散していきます。確保していたのは2時間。 時間切れは当たり前でした。
なんとか詳細化できるのは直近のスプリントのストーリーだけ。少し先は不明確なまま、見通しも立てられない。「自転車操業的な感じ」で進んでいました。
困るのはその後です。リファインメントでReadyな状態にならないので、次のスプリントプランニングは「Readyな状態にする」ところから始まります。そうなると、POがいないといけない場面が多々あります。POが中抜けでいないときは、「明日確認しますかー」と暫定で進めて、プランニングを終えることもありました。
かかっていた時間は約4時間。目標は2時間以内でしたが、全然超えていました。ふりかえりでは「プランニングつらい」という付箋が、数週間にわたって出ていました。
一時的な対応として、「人柱」を立ててみた
最初に試したのは、仕組みではありませんでした。一時的な対応です。自転車操業を脱するために、バックログアイテムを理想の状態にする役割を、開発メンバー1名に任せました。理想の状態になれば、元々予定していたリファインメントとプランニングだけで回るはずだ。そういう目論見でした。
チームはこれを「人柱たててやってみていました」と言います。
① 着手予定のストーリーを詳細化する ─ 開発1名
② 詳細化で出た不明点をPOとやり取りして解消する ─ 開発1名とPO（非同期）
③ 解消した内容をストーリーに反映する ─ 開発1名
④ プランニング ─ 開発全員
※ この期間、全員で集まるリファインメントは開催していません
やってみると、ある程度できました。ストーリーは詳細化された状態になりました。
元のイベントだけに戻したら、すぐ同じ状態になった
1人でやる形をやめて、リファインメントとプランニングだけに戻します。
しかし、 戻してみると、すぐ同じ状態になりました。
なぜ元に戻ってしまうのか。リファインメントで話す対象のストーリーは、その場で全員が初見、ここは変わらなかったからです。
人柱で作った余裕は、最初のうちは幾分かありました。ただ、リファインメントを重ねるごとに、じわじわと削られていきます。
そもそもストーリーが荒い状態でリファインメントに突入することが悪いのか。チームはそう考えました。
では、誰が詳細化するのか。本来ならPOにやってもらった方がいいのかな、という考えも浮かびます。ただ、それではまた時間がかかる。それも嫌だと思い、開発メンバーでコントロールできる形を選びました。
もう1つ決めたことがあります。1人でリファインメントの準備から本番まで済ませてしまう形は、仕組みにしない。一時的な対応でそれをやったとき、ストーリーの情報量が担当者1人とPOに閉じてしまったためです。プランニングで他の開発メンバーとの間に情報量の差ができ、そこの差を埋めるための時間を結局要してしまいました。
残ったのは、準備を1人でやり、リファインメントとプランニングはみんなでやる、という形でした。
スクラムのサイクルに「リファインメント準備時間」を置いた
そこで出てきたのが、スクラムのサイクルに「リファインメント準備時間」を設けることでした。ふりかえりのTryとして提案したのは、開発メンバーです。形にすると、こうなります。
① 着手予定のストーリーを詳細化し、たたき台を作る ─ 準備担当（木曜の準備時間）
② 詳細化で出た不明点をPOとやり取りして解消する ─ チーム全員（金曜の朝会後）
③ 解消した内容をストーリーに反映する ─ 準備担当
④ たたき台を全員で仕上げる ─ 開発全員（金曜のリファインメント）
⑤ プランニング ─ 開発全員
担当が1名なのは、POの替わりに、一貫した考えのもとで通して見るためです。詳細化しながら「POに確認しないと分からないモヤモヤ（疑問点や足りない要素）」を洗い出しておきます。
対象を次の次のスプリントまで広げているのは、バックログアイテムの順番入れ替えに柔軟に対応できるようにしたいからです。もう1つ、「おかわり」として次のスプリントのストーリーに着手できるようにしておく、という理由もあります。
洗い出した不明点をぶつける先は、毎朝、朝会のあとにあるPOとの時間でした。チームはこの時間を、POに死守してもらいました。だから、そこで確認できたことをストーリーに反映する。POとのやり取りは、この時間か、非同期。 POが100%いなくても、不明点は潰せるようになりました。
リファインメントに臨む時点では、たたき台がPOの回答を反映した状態になっています。いきなり全員でゼロから話すのではなく、そのたたき台を全員で仕上げる場になりました。認識を合わせ、改めて中身を確認して、不明点がないよねと確かめる。足りないものがあれば、その場で洗い出します。それでも残った不明点は、次の朝会で確認します。
プランニングが「計画を立てるだけ」の時間になった
リファインメントで決めないといけないことが少なくなりました。リファインメント自体は、1時間かからないくらいで終わります。見通しが良くなった、とメンバーは言います。
チームにとっての最大の効果は、リファインメントではなくプランニングの方でした。要件の確認をすることがほとんどなくなり、その名の通り「計画を立てるだけ」の時間になりました。約4時間かかっていたのが、今は1時間から1時間30分くらいです。
準備の時間も、続けているうちに軽くなっていきました。メンバーはこう書いています。
「一度流れができると、リファインメント準備は半日もいらなくなるし、リファインメントも1時間ほどでさくっと終わっちゃいます。便利です。」
半日もいらなくなったのは、1ヶ月ほど経った頃からだったと思う、とメンバーは言います。
忙しい週にこのサイクルが崩れることもありませんでした。準備がスプリントの初日にあたっていたことが効いていたのかもしれない、とメンバーは見ています。スプリントの最後のほうに準備があったら、崩れていたかもしれない、と。
あなたのチームが「つらい」と言っている場所は、本当に詰まっている場所ですか
ふりかえりに出ていた付箋は「プランニングつらい」でした。ただ、このチームが新しく時間を置いたのは、プランニングではありませんでした。詰まっていたのは、その手前だったからです。
置いたのは、リファインメント前日の半日です。整えるのは開発メンバー。POには毎朝の時間を死守してもらい、そこに不明点をぶつけました。
もちろん、この形がそのまま別のチームに当てはまるとは限りません。毎朝POと会話できる時間があったこと、開発メンバーの1人が毎週半日を出せたこと、準備がスプリントの初日にあたっていたこと。この仕組みが回った背景には、このチーム固有の条件があります。
あなたのチームが「つらい」と言っている場所は、本当に詰まっている場所ですか。
このチームの試行錯誤が、皆さんのチームへの「問い」になれば嬉しいです。
この記事は、「トナリノ」から生まれた試行錯誤の記録です。
様々なチームの泥臭い試行錯誤を、定期的に届けています。
他のチームの話も気になった方は、フォローしてもらえると嬉しいです。
Xでも同じテーマで発信しています → X（@はんそで）