■

スクラムガイドにある「リファインメントは開発チームの作業の１０％以下」という箇所について、疑問が上がっていました(Facebook上で。限定公開だったのでリンクは貼りません)。そこにコメントしたのですが、私の解釈は以下のようなものです。

リファインメントはいろんなやり方があるので、「開発チームの工数の10%」という解釈がほぼ近いと思っています(工数、作業量、エネルギー、許容量、できること、そこの言葉の捉え方はいろいろありそうです)。POとミーティングをしてもいいし、開発チームだけで相談してもいいし、定例化してもいいししなくてもいいし、開発チームタスクとして作業をしてもいいし、ミックスしてもいい。

2週間スプリントでリファインメント「イベント」を週1回実施して、スプリント前半のリファインメントでは調査タスクを発生させ、後半までに開発チームで調べておく、というチームがありました。このときはイベント(全員)＋調査タスク(担当した人)あわせて「10％以下」の対象になります。

別のチームでは、スプリント中に新しい急ぎのPBIが頻発するので、毎日１５分確保しておき、急ぎのPBIがある日は内容を調べて見積もるようにしていました。

たしかケントベックが言ってた、「新しいストーリーはホワイトボードに貼っておいて、メンバーは気の向いたときにそれを眺めて、見積もりポイントを封筒に入れる。何人分か集まったら、その平均(だか最大値だか)を見積もりとする」というのも、スクラムであればリファインメント作業になると思います。

リファインメントはプロダクトバックログの「すぐやるやつ」と「今後の見通し」を把握するためにやるので、チームやプロダクトによっていろいろな形になるようです。「10%以下」は、そちらにのめり込みすぎないような、またプロダクトオーナーがやるべきことをチームに押しつけすぎないような、バランスのための目安かなあと個人的に思っています。