# スクラムマスターを雇う時に聞いてみるとよい47個の質問
スクラムマスターへの質問というPDFがあるので、回答してみた。
定期的に自分の回答がどう変わっていくのか楽しみだ。
Scrum Master Interview Questions: Free Download of the Ebook
https://age-of-product.com/38-scrum-master-interview-questions-to-avoid-imposters-free-pdf/
## Set 1: Role of the Scrum Master 10 Questions
1. __Q 01: The Scrum Master Role as a Contradiction?__
- _The Agile Manifesto infers people over processes. Isn’t a Scrum Master — whose role is
meant to “enforce” the process — therefore a contradiction?_
- アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
- （回答）矛盾していません。スクラムマスターはチームがプロセスを守るようサポートすべきです。プロセスを守らせることで、チームの問題点が明らかになります。最初からプロセスをカスタマイズすべきではありません。対話を重視するのは明らかになったチームの問題点、改善すべき内容に対して、チームの実情にあわせて実施するものと考えています。
- （意図）チームを主導することがスクラムマスターの役割であることを理解しているかどうか。
1. __Q 02: Success Factors of “Agile”__
- _What indicators might there be that demonstrate agile practices are working for your
organization, and which of these would demonstrate your efforts are succeeding?_
- 自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
- （回答）定性的にはディリースクラムが開発チームにて回せていられるとき、プロダクトリファインメントがチーム内で活発に議論されているのをうまくいっている兆候、あるいは自分の働きが成功している兆候と捉えます。定量的な計測には２つあります。一つはプロダクトで定めたKPI。これはステークホルダー向けあるいはプロダクトの利用観点からの指標値となります。もう一つは内部品質の計測です。これには例えばサイクロマティック複雑度や循環参照の有無に始まり、テストコード成功率やカバレッジ率の低下の有無です。ビルドの失敗率の増加や、単位あたりのデプロイの回数も、指標値として有効と考えます。
- （回答）私は新人研修にてYWTふりかえりを実施していました。ふりかえり項目の一つに「今日の気分」を入れ、笑顔、泣き顔、怒り顔、普通の顔の4つをいれました。毎日その内訳を注視していました。このとき注意しなければならないのは記入のない受講者、もしくは怒り顔の受講者です。彼らは講義は実習に興味を失っているまたはその手前の兆候でした。こちらから声がけを積極的に行い、その理由がどこにあるのかを探り、彼らのストレスが解消するよう勤めました。最終的には無回答、怒り顔の受講者はいなくなり新人研修を終えることができました。任されたチームではこれに準じたサインを取り込みメトリクスとして追跡します。
- （意図）"アジャイルの成功"を示すメトリクスはありませんが、間接的な指標はいくつかあります。
1. __Q 03: Impediment Remover__
- _Should a Scrum Master remove impediments on behalf of the Scrum Team?_
- スクラムマスターはスクラムチームの代わりに障害を取り除く必要がありますか。
- （回答）障害が発生していることを指摘し、自己組織化した彼らが取り除くのを見守ります。障害を取り除くアイデアを提示します。でも取り除くことはしません。
1. __Q 04: Communication between SM and PO__
- _How should a Scrum Master communicate with a Product Owner?_
- （回答）定期的な1on1が役立ちました。私達はインセプションデッキでプロダクトの方向性とゴールを明確にしており、ゴール達成のために自分たちがなすべきことを話し合いました。これは密会ではありません。公開すべきタイミングは図ったものの、話し合った内容はすべてチームメンバーと共有していました。
1. __Q 05: The Product Discovery Process__
- _Should the Scrum Team become involved in the product discovery process and, if so, how?_
- _製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？_
- ディスカバリープロセスとはプロダクトを用いたサービスを設計するプロセスです。開発の事前に実施する場合もあれば、プロダクトのデリバリーと連携して実施する場合もあります。このプロセスにスクラムチームは可能な限り参加すべきです。スクラムチームが参加するとサービス設計時にあがった技術的な課題について早い段階で判断、あるいは判断する材料を提供することができます。またプロダクトの責任をもつプロダクトオーナーが参加することでサービスにおけるプロダクトの位置づけが明確になります。プロダクトの位置づけを明確にし、スクラムチームで共有することで、プロダクトバックログの優先順位を判断づけがしやすくなることが期待できます。
1. __Q 06: Supporting the Product Owner__
- _The role of Product Owner is a bottleneck by design. How do you support the Product Owner so that they maximize value?_
- _設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？_
- プロダクトオーナーがプロダクトバックログに専念できるよう取り計らいます。またプロダクトオーナーがプロダクトを掘り下げる上での思考の壁打ち相手となります。具体的にはリーンキャンバス、仮設キャンバスを作成しプロダクトの方向性を見つける手助けをします。
1. __Q 07: Access to Stakeholders__
- _How can you ensure that a Scrum Team has access to a product’s stakeholders?_
- _どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？_
- ステークホルダーにも事前にスクラムを理解してもらうよう説明の場を設けておきます。その上で、スプリントレビューの際には必ず呼びかけるようにします。呼び出しに応じてもらえなくても、リリース前に最初にプロダクトに触れてもらえる場を作ります。ステークホルダーは様々な立場の人がいることが想定されるため、その呼出が効果的になるように配慮します。具体的には呼び出すステークホルダーの関心事がかぶらないよう、スプリントバックログを定めるなどの配慮をします。
1. __Q 08: Stakeholders and the Agile Mindset__
- _How do you promote an agile mindset across departmental boundaries and throughout an organization and, in pursuit of that, what is your strategy when coaching stakeholders not familiar with IT?_
- _どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？_
- 最終的には関連する部署全体にスクラムを教育することです。私の戦略は次のようなものです。
1. スクラムチームへの教育
1. スクラムチームを保有する部署のキーマンへの教育
1. 関連する部署のキーマン（ステークホルダーを含む）への教育
1. スプリント計画、スプリントレビュー、レトロスペクティブ、バックログリファインメントにはオブザーバーとして参加を促します。その場でいろいろ意見をいいたがる人もいるかもしれませんが、意見は別の機会ですべて受け止め回答を与えます。
- アジャイルのマインドセットを万人に展開する近道（銀の弾）はないと考えます。実際に参加してもらい理解してもらいます。
1. __Q 09: Scrum and Senior Executives__
- _How would you introduce Scrum to senior executives?_
- _上級管理職にどのようにスクラムを紹介するか_
- 私の説明はつぎのようなものです。
1. 最初に、最近のプロダクト開発には以前のように時間をかけることが難しいことを説明します。採用するフレームワークや技術の移り変わりのタイミングが早いこと、プロダクトをとりまく環境の変化のスピードが早くなっていることを説明します。
1. そのうえで、どのように顧客にプロダクトを提供すべきかを説明します。MVPを定め効果を見極めながら次の戦略をとるアプローチの正当性を説明します。
1. 最後にスクラムによるアジャイル開発でこれらを満たすことが可能であると説明します。
1. __Q 10: Overcoming Stakeholder Resistance__
- _You’ve already provided your product’s stakeholders with training in Scrum. After the initial phase of trying to apply the concepts, when the very first obstacles are encountered, some of these stakeholders begin to resist continued adoption. What is your strategy for and experience in handling these situations?_
- _あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？_
- 私の経験で、ウォーターフォール開発に慣れたメンバーがドキュメントをつくることにこだわりすぎ、動くものがなかなかできない弊害がありました。このときはAzureDevOpsのBoardsを用いてのチケット管理を勧め、作成するドキュメントを効果的に残すかについて説明しました。
- 一方でドキュメントを殆ど残さないチームもありました。このときの弊害は、仕様の根拠が「みんなで決めたから」というものなっていたことでした。みんなで決めるのは方法であって根拠にはならない旨を説明し、やはりチケット管理のチケットに仕様の根拠をメモ書き程度で記述させるようにしました。
- （意図）この質問は、組織内のスクラムへの抵抗を克服することについてのアイデアの交換と、そのときに学んだ教訓を奨励することを目的としています。
## Set 2: Product Backlog Refinement and Estimation 7 Questions
1. __Q 11: External Requirement Documents__
- _The Product Owner for your Scrum Team frequently turns requirements documents received from stakeholders into tickets, and asks you to estimate each. How do you feel about this procedure?_
- _プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
- ステークホルダーの要求を受け入れるか否かの判断が必要です。プロダクトオーナーの考えるプロダクトにそぐわないものがあれば事前にステークホルダーと会話させ、プロダクトとしてどうあるべきかを判断します。その結果プロダクトに必要な要求であればプロダクトバックログにしてチームに見積もりを依頼します。
1. __Q 12: PO Anti-Pattern__
- _What kind of information would you require from the Product Owner in order to provide your team with an update on the product and market situation?_
- _チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？_
- プロダクトのゴールおよび周辺情報を共有するために、プロダクトをとりまくサービスのリーンキャンバスあるいはそれに類似した内容のドキュメントを要求します。そこにはプロダクトのKPIやプロダクトの目的、手法、チャネル、潜在的問題、顕在的問題が記載されており、ゴールおよびKPIを含めた周辺情報を共有するのに効果的です。存在しない場合は、プロダクトオーナーと相談してそれを作成します。
1. __Q 13: Writing User Stories__
- _Who should be writing user stories?_
- _誰がユーザーストーリーを書くとよいか？_
- ユーザーストーリーはプロダクトのゴール、あるいはプロダクトを利用するサービスを理解していれば、誰でも作成可能です。作成したユーザーストーリーはINVEST（独立している、交渉可能である、価値がある、見積もり可能、小さい、テスト可能）に基づいている必要があります。
1. __Q 14: A Good User Story__
- _What does a good user story look like? What is its structure?_
- _よいユーザーストーリーとはどんなものか？どんな構造か？_
- DONEの定義にあわせた完了条件が明確になっていることです。他のユーザーストーリーに依存しないことです。他のユーザーストーリーの機能を含めずにテストできる単位。経験したプロジェクトではチケットにこのユーザーストーリーのゴールを記載するようにしました。ゴールを明記させることで必要なテスト、実装方法が明確となる効果が得られました。
1. __Q 15: INVEST__
- _What does the acronym INVEST mean?_
- __I__ Independent: ほかのユーザーストーリーに依存していてはいけません。
- __N__ Negotiable: スプリントバックログに入れるまではいつでも変更可能です。
- __V__ Valuable: エンドユーザーに何らかの価値のある内容でなければいけません。
- __E__ Estimatable: 見積もれるサイズである必要があります。見積もりサイズ無限大というのはありえません。
- __S__ Small: スプリントで消化できるぐらいの大きさでなければなりません。
- __T__ Testable: テスト可能な単位でなければなりません。具体的にユーザーストーリーに関連のないリソースを用いるようなテストであってはなりません。
1. __Q 16: Person-hour Estimations__
- _Why aren’t user stories simply estimated in person-hours?_
- _ユーザーストーリーを時間で見積もらないのはなぜか？_
- （回答）人月はチームの能力を表すものではないからです。時間での見積もりはメンバーの技量に左右されてしまい不確実性が高く、見積もりには適していません。プロダクトにおけるユーザーストーリーの機能の難易度、重要度でサイズを見積もることは可能です。例）赤いSサイズのTシャツ（重要度を色であらわし、難易度をサイズであらわすなど）
1. __Q 17: Cluttering the Product Backlog__
- _The Product Owner of your Scrum Team tends to add ideas of all kinds to the Product Backlog as a reminder to work on them at a later stage. Over time, this has led to over 200 items in various stages. What are your thoughts on this? Can a Scrum Team work on 200 Product Backlog items?_
- _プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？_
- チームのメンバーが７人程度としても、200個のプロダクトバックログは異常な状態であると捉えます。バックログがどこからなぜ出現したかをプロダクトオーナーから聞き出す必要があります。不要な重複機能はないか、この機能により利便を提供されるのは誰かを見極める必要があります。
- それでも必要であれば次のような手段で対処します。最初に順番あるいは優先順位を決めるます。このとき狩野モデルを採用してそれぞれがどの品質に分類されるかも確認します。当たり前品質を優先させ、一元的品質を次に、最後に魅力的品質の順番に並べます。スプリント計画時にこれらの必要性を再確認し取り組むべきチケット、取り組む必要のないチケットを判断します。結果として200個すべてに取り組むときには優先順位に従いますし、不要なチケットは対応しないことになります。
## Set 3: Sprint Planning 8 questions
1. __Q 18: A Scrum Master’s Contribution to the Sprint Planning__
- _How can a Scrum Master contribute to Sprint Planning in a way that enables the Scrum Team to work only on the most valuable user stories?_
- _チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？_
- ユーザーストーリーからスプリントゴールを定める手助けをします。具体的にはプロダクトオーナーにこのスプリントを通じてユーザーに何を提供したいかを語ってもらい、それについて議論の場を作ります。議論を通じてスプリントゴールを定め、開発チームにその実現のためのプロダクトバックログを選んでもらいます。
1. __Q 19: Assessing the Value of a User Story__
- _With what metrics would you assess the value of a user story?_
- _ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？_
- コードレベルではCCN、循環参照の有無、テスト成功率を定める。これは後の拡張性や保守性を担保するために必要です。ストーリーの価値はKPIにより測定されます。KPIがない場合はそれをつくるようプロダクトオーナー、ステークホルダーに進言します。定性的にはサーベイによるユーザーのフィードバックから判断できます。
1. __Q 20: Selecting the Most Valuable User Stories__
- _How do you facilitate user story selection in a way that the most valuable stories are chosen without overruling the Development Team’s prerogative to select the Sprint Backlog?_
- _チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？_
- （回答）定量的、定性的の2つの観点を忘れないようアドバイスする。定量的にとはチームのキャパシティの見込みにマッチするかであり、定性的にとは選んだスプリントがスプリントゴールにマッチするかである。
1. __Q 21: Time Allocation During a Sprint__
- _How much of a Development Team’s capacity during a regular Sprint would you consider adequate for refactoring? Fixing important bugs? Exploring new technologies or ideas?_
- _どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？_
- （回答）ユーザーストーリーの遂行に影響を与えないことを考慮します。軍事的に部隊の３割を失うと全滅扱いされるとのことなので、３割は超えないようバッファを見込んで２割内に抑えるのが適切と考えます。
1. __Q 22: Assigning User Stories__
- _Should a Product Owner assign user stories or tasks to individual members of a Development Team?_
- _チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？_
- （回答）自分たちはチームでプロダクトを作成していること、個人への負担はチーム全体のパフォーマンスを下げることを伝えます。ユーザーストーリーの割当はチームの仕事であることも伝えます。その上で、スプリント計画時にどういう割当がチームにとって効果的かを判断し決定します。
1. __Q 23: Cherry-Picking Items__
- _How do you deal with team members cherry-picking tasks?_
- _チームメンバーによるタスクのつまみ食いをどのように扱うか？_
- （回答）これはチームの成長にとってよくない傾向です。実装しかやらないメンバーがいれば、その結果テストしか担当しないメンバーが生じてしまいます。短期的なパフォーマンスはあがっても長期的なチームのパフォーマンスには全く寄与しません。したがってこれを阻止する必要があります。開発チームにはこの事態は避けるべき事態であることを伝えます。ベロシティは下がるけれど、スプリントバックログの個数を制限し、チームの経験値があがるような割当を提案します。また日頃からペアプログラミングを実施し、メンバー間での経験の共有を推進させます。
1. __Q 24: The Almost Ready User Story__
- _A valuable user story is lacking the final user interface designs, but the design team promises to deliver on day two of the upcoming Sprint. The Product Owner for your team is fine with that, and pushes to have the user story added to the Sprint Backlog. What are your thoughts on this scenario?_
- _ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？_
- （回答）いれてはいけない。次のスプリントに回すべきです。入れなくてすむようプロダクトオーナーとステークホルダーを説得します。そのユーザーストーリーのかわりにリファクタリング、スパイク、テスト充実などを提案します。
- チームメンバーが合意すれば入れることは可能ですが、これはあくまでも例外であり認めるべきではありません。一度の例外は習慣化してしまいます。ですのでスクラムマスターは原則不可。のスタンスでこの問題に臨むべきです。
1. __Q 25: Sprint Planning Is a Waste of My Time__
- _A member of the Scrum Team does not want to participate in Sprint Planning and considers the meetings a waste of time. How do you deal with this attitude?_
- _スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？_
- （回答）このような状態は望まれない状況です。最初にスプリントプランニングのファシリテーションを点検します。問題がなければ参加したくないメンバーとの1on1を実施し、理由、原因を探ります。理由、原因が適切なものであればあるいはチームが受容可能であればそれをレトロスペクティブの場で提案させ、スクラムの仕組みの中で解決を図ります。そうでない場合、人事権を有するマネージャーに任せます。
## Set 4: Daily Scrum 7 questions
1. __Q 26: The Formal Daily Scrum__
- _Would you recommend formal Daily Scrums for all teams, no matter the size or experience level?_
- _チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？_
- （回答）薦めます。最初はチームのメンバーのサイズ、参加メンバーのキャリアに関わらず実施します。チームのサイズが７人を超える場合はあらかじめ７人以内に収まるようチームを分けておきます。チームメンバーのサイズが十分に小さい場合、二人とか、状況に応じて開催のスタイルを変えるほうが効果的かもしれません。
1. __Q 27: Impediments__
- _Do you expect experienced team members to wait until the next Daily Scrum in order to ask for help overcoming an impediment?_
- _なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？_
- （回答）待つ必要はない。いつでも声をあげてよい。あげにくければスクラムマスターに相談してほしい。
1. __Q 28: Leading a Daily Scrum?__
- _How do you handle team members who ‘lead’ Daily Scrums, turning the event into a reporting session for themselves?_
- _スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？_
- 進行を持ち回り制にすることを提案してみる。リード役の彼にはチームの状況を確認するためにはいろんなやリ方があることを示し、気づかせることを第一に考える。
1. __Q 29: Waste of My Time?__
- _How do you manage team members who consider Daily Scrums to be a waste of time and are therefore either late, uncooperative, or simply don’t attend?_
- _スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？_
- （回答）このような状態は望まれない状況です。最初にデイリースクラムのファシリテーションを点検します。問題がなければ参加したくないメンバーとの1on1を実施し、理由、原因を探ります。理由、原因が適切なものであればあるいはチームが受容可能であればそれをレトロスペクティブの場で提案させ、スクラムの仕組みの中で解決を図ります。例えば開催時刻の変更など。そうでない場合、人事権を有するマネージャーに任せます。
1. __Q 30: Stakeholder Attendance__
- _Your team’s Daily Scrums are not attended by any stakeholder. Should that change?_
- _スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？_
- （回答）私の理解、経験ではステークホルダーは参加する必要はありません。このため状況を変える必要はないと考える。ステークホルダー参加により状況確認が阻害されることを排したい。
1. __1Q 31: Daily Scrum with Distributed Teams__
- _How do you approach Daily Scrums with distributed teams?_
- _分散チーム間のスタンドアップをどのように進めるか？_
- （回答）Teams、Zoomなどを利用してスタンドアップミーティングを実施します。ポイントは毎回定刻に実施すること、開始時刻数分前に会議を開き毎回アイスブレーク（雑談）をすること、少なくともスクラムマスターは顔を見せること、です。ボードはMiroなどを利用するのをおすすめします。
1. __Q 32: The Scrum Board__
- _Can you draw an example of a Scrum Team’s Kanban board — right now?_
- _スクラムチーム用の物理カンバンボードをいま書いてください_
- ToDo、Doing、Code Review, Test, Doneの5レーンの横軸を基本にします。縦軸に緊急レーンを設けるかはチームを運営して決めます。最初から緊急レーンを設けると、すべてが緊急レーンに入ってしまうからです。
## Set 5: Sprint Retrospectives 6 questions
1. __Q 33: Participants of a Retrospective__
- _Who should participate in a Sprint Retrospective?_
- _だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？_
- （回答）プロダクトオーナーもふりかえりには参加すべき。プロダクトオーナー、開発者、スクラムマスターにてスクラムチームです。レトロスペクティブの議事録はチーム外には非公開であるべきです。
1. __Q 34: Team Health__
- _Should you check a team’s health during a Sprint Retrospective, or is doing so unnecessary? If you do, how would you go about it?_
- _チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？_
- （回答）チームの健全性というテーマではないが、例えばコミュニケーションに困っていないかなどを確認することは可能。コミュニケーションについて、心配事の有無について無記名で５段階アンケートをとるなど実施するとよい。Teamsのアプリ、Office365のFormsなどアンケートをとるツールはいくらでもあります。
1. __Q 35: Retrospective Formats__
- _What Sprint Retrospective formats have you used in the past?_
- _過去に使ったふりかえりのフォーマットはどんなものか？_
- KPTをベースにふりかえりを利用しています。意見が出ない場合は、Keepとしてやったこと、わかったこと、感謝したことを、Pではプロジェクトで気になっていることを観点として示し、間口をひろげたりしました。Fun/Done/Learnも有効です。日々のふりかえりではYWTという日本発のフォーマットを使いました。
1. __Q 36: Retrospective Fatigue__
- _How do you prevent boredom during Sprint Retrospectives?_
- _どうやってマンネリを防いでいるか？_
- マンネリを防ぐためにというわけではありませんが、会の冒頭で自分たちチームのミッションを確認するようにしています。これはインセプションデッキの我々はなぜここにいるかであることが多いです。こうすることでふりかえりの焦点が明確になると考えています。
1. __Q 37: Not Delivering on Action Items__
- _If your team is picking reasonable action items but not delivering, how would you address the situation?_
- _チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？_
- 選択するアクションを一つに限定する。そこでも行動できていない場合はチームに何かが起きていると考え、障害の除去に務める。あるいは選択方法、選択基準に問題があるのかもしれないので、選択基準を見直してみる。またその実際に行動できていない、という問題をレトロスペクティブで提出してみます。
1. __Q 38: Follow-up on Action Items__
- _Would you recommend following up on action items? If so, how would you do that?_
- _どうやってアクションアイテムのフォローアップを薦めるか？_
- デイリースクラムにてリマインドし、意識を向かわせます。あるいは次のレトロスペクティブにて前回のアクションの成否をチームで議論します。
## Set 6: Agile Metrics 9 questions
1. __Q 39: Volatile Velocity__
- _Your Scrum Team is consistently failing to meet forecasts and Sprint Goals, and their velocity is volatile. What are the probable reasons for this problem, and how would you address it with the team?_
- _あなたのスクラムチームは常に予測とスプリントの目標を達成できておらず、その速度は不安定です。 この問題の考えられる理由は何ですか？また、チームでどのように対処しますか？_
- （回答）考えられる原因と対策は
1. スプリント計画が適切でない スプリントバックログを抽出するプロセスを点検します
1. DONEの定義が曖昧である DONEの定義を明確にするための会議を設ける
1. テストしにくい、開発しにくい、などの技術的負債の存在 技術的負債の解消をユーザーストーリーとして計画します
1. __Q 40: Suitable Agile Metrics__
- _What suitable agile metrics have you used in the past?_
1. __Q 41: Qualitative Metrics__
- _What qualitative agile metrics would you consider tracking?_
## Set 7: How to Kick-off a Transition to Scrum
1. __Q 42: Kicking off Scrum__
- _How would you prepare to kick off a transition to Scrum?_
1. __Q 43: Creating the First Scrum Team__
- _How would you create the first Scrum Team?_
1. __Q 44: First Steps of a New Scrum Team__
- _What do you recommend a newly formed Scrum Team works on first?_
## Set 8: Scrum Anti-patterns
1. __Q 45: Scrum Master Anti-Patterns__
- _What Scrum Master anti-patterns do you know?_
1. __Q 46: Sprint Retrospective Anti-Patterns__
- _What anti-patterns do you know of that can happen during a Sprint Retrospective?_
1. __Q 47: Improving as a Scrum Master__
- _How can you (as a Scrum Master) identify where you need to improve?_
EOF
