スクラムマスターを雇う時に聞いてみるとよい質問に答えてみた: スプリントプランニングについて
「スクラムマスターを雇う時に聞いてみるとよい 38 個の質問」に答えていくシリーズです。
今回は「スプリントプランニングについて」のテーマで回答していきます。
他のテーマについては以下からお読み頂けます！
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
「現状を正しく把握してから取り組む内容を選ぶこと」でチームが最も価値のあるストーリーに取り組めるようになると考えました。
私は普段スクラムイベントにはファシリテーターとして関わることが多いので、プランニング冒頭に以下のような問いかけをすることで貢献したいと思いました。
「現在のプロダクトバックログ（PBL）に存在していないが、今/次スプリントで取り組まなければならない課題を持ってる人はいますか？」
→ あれば、追加してもらう。まずは検討のテーブルに載せてもらう「現在の PBL （今スプリントで取り組む可能性のある範囲）は最も価値のある順・優先順位通りに並んでますか？」
「この並び順に違和感がある人はいますか？」
→ 2, 3 で改めて順番の合意を得る
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
可能であれば、ユーザーの行動ログなどから得たデータをもとに判断するのが良いと考えました。
期待しているものの要件としては (1) ユーザーの行動が再現できるようなデータであること（なるべくローデータ） (2) ハック（意図的な操作）できない数字であること を想像しています。
ユーザーストーリーは「ある数値の改善を期待する仮定」から作られると考えていまして、その仮定と紐づいてるとより良さそうだと思いました。
一方で受け入れ難いメトリクスについては「ハックできてしまうもの」と考えました。都合の良い前提に基づく仮定であれば、正しい判断ができないと考えたからです。
チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
この記事で回答した 1 つ目と同様のアプローチをとります！
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
それぞれこんな感じで考えています。
リファクタリング: すでに実装していた箇所の改修をするのであれば、その改修には毎回含まれるのが理想だと考えてます。かける時間だけで考えれば、リファクタリング > 目的の改修 でも良いのではないかなと思っています。リファクタリングについては以前少しだけ考えを書いてみたので、ご興味ありましたらどうぞ！
重要なバグの修正: バグの修正であってもプロダクトバックログアイテム（PBI）として管理するのが良いと考えています。「バグ修正だからこの時間の範囲内で対応する」のではなくて、他の PBI と比較して優先順に対応するのが良いと考えてます（重要なのであれば PBL の上に来るでしょうし）。
新しい技術やアイデアの調査: 前提として新しい技術やアイデアを調査することを目的とするのではなく、 PBI の実行に併せて調査するのが良いと考えています。以下の 2 点から、最大でも 1/4 スプリント以下の時間をかけることになると考えてます: (1) LeSS では 1 つの PBI の大きさは 1/4 スプリント程度と言われています。(2) PBI はユーザーに価値を提供できる単位で作成するのが良いとされています（調査以外にも PBI を実行するための時間が必要）
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナー（PO）をどう扱うか？
まずは PO に、なぜ個人にストーリーやタスクを割り当てたいのか聞いてみます。何かしらの課題があってそのような対策をしているのであれば課題の解決方法を一緒に考えますし、そもそも個人に割り当てる以外の選択肢を持っていない（知らない）のであれば説明します。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
つまみ食い = プランニングで計画しなかった PBI をちょっとだけ手を出す（が PBI 自体は PBL に残している）状態 と仮定して考えます
つまみ食い対象の PBI を実行し終える程度のサイズに切り出すこと（= リファインメント）を提案し、切り出した PBI は持っていってもらうことを提案します。
やりかけの PBI がたくさんある状態は、チーム内での学習や協働を損ねるために避けたほうが良い状態だと考えています（以前このあたりの考えを書いてみたのでご興味ありましたらどうぞ！）。スクラムの一連のフローはチーム内の協働や学習を促進する一面があると考えているため、イレギュラーな "つまみ食い" 状態でなくすのが良いと考えました。
そもそもつまみ食いってどんな状態なんでしょう！ 😅
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
以下で出た「Ready の定義」に似ていますね。 Ready の定義についての考えは以下にて記載してますのでご興味ありましたらどうぞ！
ストーリーが「確定」することはスプリントバックログに入れるにあたり必要な要素ではないと考えています。
そのため、入れてしまって良いと考えてます。
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
時間の無駄だと考えているポイントを聞き、レトロスペクティブで対応を考えるのが良いと考えます。
レトロスペクティブの中で建設的な議論ができなければ、スクラムマスターや（いれば）マネージャーが 1on1 にて本人と対話するのが良いと考えてます。一向に改善せず、チームへの悪影響が大きいようであれば異動も検討することになると考えてます（ここまで行くと大抵悪影響大きそうですが）
〆
質問数はそれほど多くないと思うのですが、想像しにくいところやあまり深く考えてないところがあり、回答するのに少し苦戦しました。
今回の記事で 3 つ目ですので、折返しですね。あと少し頑張ります！
他のテーマはこちらから！
よろしければサポートお願いします！いただいたサポートは入浴剤や飲み物など、息抜きに使わせていただきます🤗