なぜプロダクトバックログリファインメントはスクラムイベントに入っていないのか？

Ryutaro YOSHIBA @ryuzee

「なぜスクラムガイドではプロダクトバックログリファインメントをイベントとしていないのですか？」という質問を頂いたので、ぼくの見解をつらつらと。 まずプロダクトバックログでやらないといけないのは、最新の状態に保つこと、直近のスプリントで着手しそうなものの準備ができてること

Ryutaro YOSHIBA @ryuzee

(続) プロダクトバックログがこの状態になっていればOKで、いつもちょっとだけ先のことを見通しながら手入れをしておけばよい。大事なのは「プロダクトバックログの状態」ってことになる。 じゃあ、いつ手入れするのか、だけど「思いついた時にやる」だと最初はできない

Ryutaro YOSHIBA @ryuzee

(続) なのでぼくの場合は「スプリントの中間くらい」に固定の枠をとっていることが多い。ペースメーカーにもなるので経験が多くないチームには有効。一方でPOと開発チームがどれくらいの時間一緒にいられるのかにも依存していて、POと開発チームで毎日ちょっとづつやっても構わない。

Ryutaro YOSHIBA @ryuzee

(続) 最近のスクラムガイドはHowの部分を取り除くようになっている。例えばバーンダウンチャートは数年前に取り除かれたし、デイリースクラムの3つの質問も同様。 大事なのはプロダクトバックログを最新に保ち上位を着手可能にすることなので、やり方(How)はそれぞれ考えろ、ってことじゃないかな。

Ryutaro YOSHIBA @ryuzee

(続) 現実としては、僕は1週間スプリント推奨なので、リファインメントをやるとしたら3日目くらいまでにはやっといた方がいいかなとは思う。リズムという面で開始時間を固定してイベント化してやる方が最初は楽。ただここで幅広に話すと時間いくらあっても足りないので、あくまで直近分に集中

Ryutaro YOSHIBA @ryuzee

(続) プロダクトバックログ全体の手入れはプロダクトオーナーが継続的にやればいい(やってくれ)。遠い先のことに開発チームのリソース使いすぎると成果の量が減るので、そこはよーく考える必要がある。一方で直近分の手入れが出来てないとPOは自分の首を絞めることになる

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ryuzee んー。りゅーじーさんの見解はわかるけど、直接的な回答になっていないような？たとえば、Nexusではプロダクトバックログリファインメントはイベントになっていますよね。Scrum Guideではなぜなくて、Nexusではなぜあるのか？っていう話のほうが本質なのでは？

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kyon_mm @ryuzee りゅーじーさんの言っていることは間違っていないけど、それはScrum Guideに書いてあるプロダクトバックログリファインメイントの解説っていう気がするなーっていう。「これはプロダクトオーナーと開発チームが協力して行う継続的なプロセスである」とか

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kyon_mm @ryuzee 「いつどのようにリファインメントをするかは、スクラムチームが決定する」の1実装を紹介してくれているのは理解できるんですけど。っていう。

Ryutaro YOSHIBA @ryuzee

@kyon_mm あー。ナイス突っ込みw。スケール系はコアの上に実装を足してるんですが、それは同期点が必要(アドホックに複数チームでやるのは難しい)というスケール上の課題解決のためであって、実装の一例でしかないと思うんですが？

Ryutaro YOSHIBA @ryuzee

えーと 1) スクラムガイドではHowを取り除いている 2) 重要なのはプロダクトバックログが最新化されていて、上位が着手可能であること 3) そうなるように自分たちで考えろ。実装はたくさんある。 で、論点どこ？ @kyon_mm

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ryuzee 1かなーと思っています。Howを取り除いているのかどうかが僕にはあまりわかっていないのもあるけど。プロダクトバックログリファインメントがHowであってスプリントプランニングやデイリースクラムやスプリントレトロスペクティブがHowでないのはなぜか？っていう感じ。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kyon_mm @ryuzee つまり、イベントとして定義しているものの明確な基準ってなんですかね？という。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@kyon_mm @ryuzee 〜っていう状態を保つのが目的だー。っていうだけでいうなら、いまのスクラムイベントだって「チームで決めろ」で終わっちゃうじゃないですか。っていうところですね。

Ryutaro YOSHIBA @ryuzee

@kyon_mm 分かる。とはいえ、それを言えるようになったら守モード卒業でいいんじゃないかとも思うんだな。フレームワークは小さい方がいい、というのがスクラムの思想にあって（だからテクニカルも入ってないし）、作成者として絶対に譲れない最低限だけが残ってるのではないかと。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ryuzee そこが何かを知りたいという知的探究心に対して回答があると、僕みたいなオタクが喜ぶじゃんって話です！（だんだん変わってきたぞ（いつもの話じゃーん

Ryutaro YOSHIBA @ryuzee

@kyon_mm えっと、Jeffが明確に言ってるのは「minimal meeting」ね。チーム全体の速度を下げるミーティングは最低限必要なものに限るべきだと。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ryuzee そうそれ！それの基準がわからないっていう話ですー。どう考えても、あの二人の気持ち次第な感じがする。

Ryutaro YOSHIBA @ryuzee

@kyon_mm きょん君の関心が見えたw。ちなみにスクラムのオリジンはうまく行っているチームのやり方をまとめたもんで、多分に経験主義的(別に否定的な意味では言ってないよ)ですね。デイリースクラムはベル研のうまくいってるチームがやってた、という理由だし

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@ryuzee そうなんですよねぇ。いいんですけど、どの論文とか書籍読んでも、そういう話な気がしていて。後付でもいいから基準作って、ある程度の定理化というかそういうところがほしいんだよなーと。システム設計できてないんですよねぇ。

Miho🍺Nagase @miholovesq

@kyon_mm @ryuzee Sprint Planningは2011年のスクラムガイドではSprint Planning Meetingだし、リファインメント（詳細化、CSにおいては抽象化の反対語）は計画の中でされてた。スクラムイベントの1つ目はスプリントそのもの。てことはきょんの言うように「スプリントは計画されてろ」でいいんだと思う。（続く）

Miho🍺Nagase @miholovesq

@kyon_mm @ryuzee （続き）ただしスプリントnが始まるまでスプリントnの計画すんじゃねーぞ、スプリントに集中しろって話で、リファインメントはスプリントmのための活動であってスプリントnのイベントではない。て理解です。イベントははっきりくっきり、逆にロールよりチームが強調されてる気がするね。

きょん＠アジャイルコーチ、システムアーキテクト @kyon_mm

@miholovesq @ryuzee スプリントnのための活動はスクラムイベントにするけど、スプリントmのための活動はスクラムイベントにしないっていうことかな？

Miho🍺Nagase @miholovesq

@kyon_mm @ryuzee そう、スクラムガイドの構造から想像してるだけなんだけどね。スプリントnのときにスプリントnの準備をしてたんじゃ遅いんでリファインメントを独立させたって経緯があって、定義されてるスクラムイベントはあくまでスプリントnに集中させるためのものなのでは、と。