私はソフトウェア エンジニアリング試験の復習をしていますが、質問の 1 つに疑問を感じました。チームが 10 日間ユーザー ストーリーを進めていないバーンダウン チャートが表示されました。質問は、「スクラムマスターがこの時点でとることを検討する可能性のある行動を概説し、正当化する」でした。
スプリントを止めるなど、抜本的なアクションを考えました。次に、ペアプログラミングを割り当ててユーザーを支援し、ユーザーストーリーをさらに分解することを検討します. 他に提案はありますか？(この質問は、過去の論文で 4 点の価値がありました)。
私は個人的にこのような抽象的な質問を嫌います-あなたは実際に「良い」答えを与えるのに十分な情報を持っていないからです。スプリントはどのくらいですか？チームは何をしてきましたか？進歩の欠如の根本的な原因は何ですか？これらはすべて、あなたがチームのスクラムマスターである場合にすでに知っていることです。10日後にバーンダウンチャートを見て、何をすべきかを理解するだけの立場になってはいけません。
例えば：
たぶん、チームはプロジェクトのコンテキスト外で「緊急」タスクを実行するように任命されています
部分的に完了しているが、ボトルネックのために完了していないストーリーがある可能性があります（たとえば、利用可能なテスター、デザイナー、または最終サインオフのPOがないため、ストーリーが完了していません）
ストーリーが大きすぎて時間がかかりすぎている可能性があります。または、ストーリーが非常に複雑で、大きな泥だんごで調整が難しいシステムの領域が公開されている可能性があります。
実際の答えは、実際の作業状況によって異なります。私が答えを与えることを余儀なくされた場合、それは次のようになります：
私がファウルした理由を理解するためのリマインダーを書いて、問題の10日後に対処すべき問題があったことだけを理解しました。
スプリントの回顧展でこのトピックを取り上げるためのリマインダーを書いてください-何か悪いことが明らかに起こっているので
ボトルネック/問題が何であるかを理解し、それに対処してみてください。自主的な問題解決が得意なチームがあれば、少なくともいくつかのことを成し遂げられるように、全員が1つのストーリーに群がる作業モードに切り替えることをお勧めします。
...しかし本当の答えは「それは依存する」です;-)
完全な答えを出すのに十分な情報はありませんが、私の経験では、スクラム マスターとして最初に行うことは、時間の経過に伴うタスク時間 (ストーリー ポイントではなく) をプロットするバーンダウン チャートを見ることです。
時間は正しく消費されているのに、ストーリー ポイントが静的なままであることはよくあることです。チームはスプリントが終了するまでテストを終了し、スプリントが終了するまでストーリーが「完了」しないため、「ミニウォーターフォール」と呼ばれることがよくあります。
シナリオに関する私の推測が正しければ、スクラム マスターとして、チームができるだけ早くストーリーを「完了する」ことに集中できるようにするために、スプリント回顧展でチームがこのように取り組んでいる理由を説明することに時間を割きます。可能であり、WIP を削減します。
これがおそらく起こっている理由の根本原因分析? それはスキルギャップですか？チームとして、これらのユーザー ストーリーにアプローチする方法を知っているか、スプリント計画セッション中にユーザー ストーリーをタスクに分割したか、PO はプロセス全体で十分に協力的か?
適切なスプリント計画が必要であり、製品のバックログ グルーミング セッションも実施されていれば、これらの問題を回避できます。
さらに、チームが技術環境/ドメインなどに慣れていない場合に採用できるさまざまなテクニックがあります。
最後に、彼らがチームとして失敗するのを許し、スプリントのふりかえりの間に取り上げます。
これは、スクラム マスターが効果を発揮できる場所です。優れたスクラム マスターは、毎日の障害ログを取得し、これが発生しないように積極的に取り組んでいたはずです。
これらは私の 2 セントです。受験の参考になれば幸いです!