新任スクラムマスターがチームに聞くべき20の質問

翻訳記事

本記事は、Stefan Wolpers さんの「20 Questions New Scrum Masters Should Ask Their Teams to Get up to Speed」の翻訳です。翻訳にあたって、Stefan さんの許諾をいただいています。誤字脱字・誤訳がありましたらご指摘いただければ幸いです。

TL; DR: 着任スクラムマスターが聞くべき20の質問
新任スクラムマスターとしてロープの学習を始める
新任スクラムマスターのための20の質問
まとめ – 新任スクラムマスターとスクラムチーム
1. 関連記事
本記事の翻訳者:

TL; DR: 着任スクラムマスターが聞くべき20の質問

着任したスクラムマスターであるあなたに20の質問を与えましょう。これらを質問するのに60分間のタイムボックスで収めることができます。あなたが参加する新しいスクラムチームが現在どのようにプロダクトを提供しているのかを学び、スピードを上げていきましょう。プロダクトバックログの鑑識、チームの課題や技術的負債のメトリクスまで知る必要があります。印刷可能なテンプレートをダウンロードして利用してみてください。

テンプレートをダウンロード

20の質問のテンプレートをダウンロード

新任スクラムマスターとしてロープの学習を始める

先日、新しいスクラムマスターを探しているチームのプロダクトバックログのリファインメントに参加することになりました。最初は半信半疑でした。私はそのプロジェクトについて、CMSベースの商用Webサイトというくらいの知識しか持つことができず、リファインメントセッションは60分のタイムボックスとなっていました。また、チームメンバーとは「こんにちは」くらいの挨拶程度でほとんど会ったことがありませんでした。

そこで、チームに関連したトピックからなるアンケートを用意してみました。スクラムチームのこともっと知り、スクラムチームから聞き、いくつかの作業アイテムを改訂したいと思ったからです。必要に応じて、準備した質問のうち1つを尋ねました。驚いたことに、そのインサイトは予想していたよりもはるかに適切であることがわかりました。特に、比較的容易にプロダクトのデリバリーを改善するための簡単に手に入る「スクラムの実」を特定することができました。スクラムマスターとして以下については覚えておいてください。ステークホルダーは、「スクラムチーム」が価値があり、リリース判断可能で、「完成」したプロダクトのインクリメントを定期的に提供できるかどうかを常に判断しています。

新任スクラムマスターのための20の質問

1. プロダクトバックログはどれくらい大きいか？

私は、チームが扱うことができる3つまたは4つのスプリントよりも大きなプロダクトバックログを信頼していません。プロダクトバックログがこの閾値を超えている場合、プロダクトオーナーは、何らかの手助けを必要としているかもしれません。

2. プロダクトバックログのアイテムの典型的な消費期限はどれくらいか？

5ヶ月間手をつけていないプロダクトバックログのアイテムは、陳腐化しています。アイデア、リマインダー、その他の価値の低いアイテムでプロダクトバックログを散らかすと、ノイズが増えます。結果として、スクラムチームが価値を提供する妨げとなる可能性があります（明らかに私は「Product Backlog forensics」のファンです。）。

3. 平均リードタイムはどれくらいか？

リードタイムとは、アイデアがプロダクトバックログに追加されてから提供されるまでの期間です。

先述のセッションでは誰もこの質問に答えられませんでした。しかし、実際には、リードタイムは、スクラムが組織にうまく採用できるかどうかを知ることができる数少ない指標のひとつになります。

ぜひ、「アジャイルメトリクス〜良い指標・悪い指標・酷い指標」も読んでください。

4. プロダクトバックログに現在のチームメンバーが知らない作業アイテムがあるか？

その場合は、該当するプロダクトバックログアイテムはもはや価値がなくなっているかもしれません。再度のリファインメントやそれらのアイテムの削除を検討してみてください。

5. どのくらいの頻度でプロダクトバックログのリファインメントを行っているか？

リファインメントは継続的なプロセスです。しかし、新任スクラムマスターとしては、週に一度、チーム全体でプロダクトバックログのリファインメントセッションを行うとよいでしょう。

6. プロダクトバックログのリファインメント中に並行して取り組んでいるアイテムはどれくらいあるか？

理想的には、チームは、次の2〜3回分のスプリントで実施できる以上の作業アイテムに取り組むべきではありません。そうしなければ、決してスプリントバックログに入らないような作業アイテムにリソースを割り当てるリスクが非常に高くなります。

7. プロダクトバックログアイテムごとのリファインメントに通常どれくらい時間がかかっているか？

リファインメントの対象は、スプリント1〜2回分にすべきです。そうでないならば、プロダクトオーナーには、リファインメントセッションに向けたアイデアの適切に準備するために何らかの手助けが必要かもしれません。

8. どのようにプロダクトバックログのアイテムを作成しているか？

プロダクトオーナーとの共同作業なのか、それともプロダクトオーナーが作業アイテムを書き、開発チームがそれらの作業アイテムを見積もるのか？

プロダクトオーナーは、プロダクトバックログアイテムの「テクニカルライター」のようなものになり、その後に、チームによる見積もりを行うようになる傾向があります。プロダクトバックログのアイテムの作成は、チーム全体の共同作業にすべきだと提案します。「Essential XP: Card, Conversation, Confirmation」を思い出してください。

9. プロダクトバックログのアイテムの議論をどこでしていますか？

リファインメントセッション中だけですか？または、Slack やアイテムのチケットのコメントで議論していますか？例えば？

どのチームにもそれぞれの習慣があります。Confluence, Jira, GitHub, Slack を活用してコメントすることは、組織内のコミュニケーションとして有効な手段なのかもしれません。これがスプリントバックログに作業アイテムが選択される前に限っては問題ないでしょう。ただし、重要な部分を後で議論することは問題になります。スプリントゴールが危うくなる可能性があるからです。

10. 受け入れ基準は誰がどのような形式で書いているか？

プロダクトオーナーは「完成」の定義にしたがって開発チームと協力し、チームが何を開発する必要があるかを共有する必要があります。

11. どのようにプロダクトバックログのアイテムの作業量を見積もっているか？

スクラムチームが見積もりをする場合、作業アイテムの見積もりプラクティスはたくさんあります（代わりに、#noestimates や、同じようなサイズの作業アイテムを作成することも検討できます）。何を開発すべきかをチームメンバー全員で共有することに重点をおくべきです。見積もりは、副作用であり、主目的ではありません。

12. 工数とストーリーポイントのどちらで見積もっているか？

工数（man-hours）で見積もることは、まったく見積もりをしないよりもましです。しかしながら、特にレガシーコードや技術的負債を抱えている場合は、ストーリーポイントの方がよいでしょう。ストーリーポイントにはバッファを組み込めるため、予測可能性とステークホルダーとのコミュニケーションが容易になります。

13. チームで意見が分かれる場合にどのような見積もりプロセスを実践するか？

できれば、チームの見積もりプロセスを実際に観察してみてください。念のために以下を聞いておくとよいでしょう：「その方法は、典型的な［投票］▶︎［議論］▶︎［再投票］のサイクルなのか？」や、「見積もりをいつ、どのように選ぶのか？」（例えば 50:50分割や、3×3と3×5 で、どれを選ぶのか？または、多数決分割で、2×3と4×5を選ぶのか？または、見積もりの範囲を例えば2〜8で選ぶ場合もあります）。チームビルディングの状態についてより詳しく知るにはよい方法です。

14. スプリントバックログでの作業アイテムのサイズの典型的な分布はどうか？

この質問は、チームの生産性のスイートスプットがどこにあるのかを、スプリントバックログの構成に基づいて把握しようとしているものです。私の観察では、スプリントバックログが1つか2つの大きなプロダクトバックログアイテム、中程度のストーリー、そしていくつかの小さなストーリーで構成されている場合、スクラムチームが機能することが多いです。

15. スプリントの終盤に作業アイテムの再見積もりをしているか？もしそうなら、どんな状況でそれをするのか？

プロダクトバックログのアイテムが当初の見積もりから大きく外れているとわかった場合は、必ず再見積もりを行うべきです。再見積もりは、スプリントレトロスペクティブの良いデータポイントとなります。

16. 最近の3回分のスプリントのベロシティはどうか？

スクラムチームは、自身のベロシティや生産性を知っているべきです。そうでなければ、改善できるのでしょうか？

17. 1回分のスプリントで完成しないユーザーストーリーはどれくらいあるか？またのその理由は？

もしチームが強気で、スプリントのはじめの段階で取り合え使える以上のプロダクトバックログのアイテムを選択している場合、それでも開発チームがスプリントゴールを達成できれいれば心配する必要なありません。しかしながら、開発チームが定常的に、作業アイテムをボードに残してしまっていて、スプリントゴールを達成できていない場合、これは新任スクラムマスターにとって大きな懸念事項となるはずです。「 Scrum: The Obsession With Commitment Matching Velocity」も合わせて読んでみてください。

18. スプリントバックログのアイテムを変更していますか？もしそうなら、どのような状況で変更しているか？

プロダクトバックログのアイテムがスプリントバックログとして選択された後に、変更されることはありますか？

開発チームが問題に直面した場合に、作業アイテムを小さくすることは決して素晴らしいことではありませんが、受け入れることはできます。小さく削減された形の作業アイテムがまだ価値をもたらし、スプリントゴールが達成できるのであればです。しかしながら、スプリントプランニングの後のそれらの拡張は、開発チームが同意し、プリントゴールが損なわれることがなければ、許容範囲ないです。

19. 技術的負債のレベルをどう考えるか？

新任スクラムマスターとして、技術的負債の現在のレベルと、他のスクラムチームや外部のサプライヤーへの依存関係について、全てを知りたいと思うはずです。これらの課題は、スクラムチームがプロダクトインクリメントを提供する能力に直接影響を与えます。「Technical Debt & Scrum: Who Is Responsible?」も合わせて読んでみてください。