タスクの変更をスプリントバックログに記録する方法
モバイルゲームプロジェクトでは、スクラムを1年以上使用しています。 mountaingoatsoftware ウェブサイトの1つ here とほぼ同じように、コルクボードに固定された印刷されたExcelシートを使用します。スプリント中は、主に設計で顧客の承認を得て、そのタスクを完了としてマークする必要があります。
タスクの所有者がタスクを完了すると、進行状況セルに疑問符が表示され、タスクが承認されると、承認待ちの状態になります（仕事がまだ承認されていないことがわかっていることを除いて、バーンダウンチャートではゼロと同じように機能します）。ゼロを設定します。そうしないと、顧客が何らかの変更を必要とする場合、設計者はそれらの変更を組み込む必要がありますが、オンラインで解決策を見つけることができないという固有の問題に直面しています。
電子メールまたはチャットでフィードバックを提供する製品所有者を除いて、チーム全体が併置されます。次のシナリオを考えて、問題の解決を手伝ってください：
4日目に、タスクの所有者がタスクAに疑問符を付けて承認待ちとしてマークした（つまり、推定時間を消費し、最後から作業を終了した）毎日のスクラムを実施しました。
スクラムマスターはシートからメモを取り、デイリーバーンダウンチャートを生成し、利害関係者にレポートを配布しました
日中、お客様は完了したタスクを確認し、メール/チャットで変更を求めます
タスクの所有者は数時間を費やしてそれらの変更を完了し、レビューのために再度送信します
5日目に、タスクオーナーと面談し、チームが完了した作業について通知する
私の質問は：
スプリントバックログでどのように報告しますか？ 5日目に疑問符を付けると、バーンダウンチャートに費やされた時間が失われます。
5日目の進捗に時間を費やす必要がありますか？しかし、その後、作業は進行中ではなく承認中です
別のタスクを追加し、5日目の進捗セルの実際の見積もり列と疑問符に費やした時間を記録する必要がありますか？しかし、その後、タスクAは不完全なままです。また、多くのタスクで発生するため、実行可能とは思えません。承認サイクルは、タスクが最終的に承認されるまで数回発生します。
この追加の作業/変更により、保留中の他のストーリーの時間が確実に短縮されます。したがって、この状況にどのように対処しますか。
SCRUMが透明性である場合の目標。チームに承認プロセスが設定されている場合、タスクは承認されるまで実行されません。そのタスクを完了するために費やしたすべての時間を記録する必要があります。簡単な解決策は、余分な時間数で書き込むことです（たとえば、作業を増やすたびに、タスクに「+1」または「+4」を追加します。
あなたが提案したように、他の選択肢は別のタスクを追加することです。これは頻繁に発生するため、このタイプの作業では、すべてのストーリーに追加のタスクを含める必要があります。それが起こることを知っているなら、あなたはそれを計画するべきです。 「レビュー後の作業」というタスクを追加して、平均して何時間費やすかを見積もります。その計画の一部を作ります。
この追加の作業/変更により、保留中の他のストーリーの時間が確実に短縮されます」_。
それがあなたがそれが時間を短縮することを意味するなら残り他の物語のために、そうです、そうです。 「この状況にどう対処するのか」とはどういう意味かわかりません。あなたはすべての関連情報を記録することによってそれに対処します。スプリントの最後に到達し、一部のタスクが完了していない場合は、回顧展でそれについて話し、次のスプリントでタスクに取り組みます。
要するに、費やしたすべての時間を追跡する必要があります（または、時間の追跡を完全に停止して、ストーリーポイントと小さなストーリーに焦点を当てます）。時間がなくなったら、回顧展でそれについて話し、チームに役立つ解決策を見つけてから、次のスプリントをより良くするようにしてください。
@Martin Maatが指摘したように、スプリント中にユーザーストーリーの範囲を変更することを許可していますが、これは良い習慣ではありません（POからでもかまいません）。これが頻繁に発生する場合、チームにとってイライラする可能性があり、リリースの計画が非常に困難になります。
これを脇に置いて、状況を一般化することができます。スクラムのタスクは、チームがより多くを知っていると発生する可能性があり、一部のタスクが表示されるだけであることはコメントになりません。
その場合、私は単に別のタスクを作成してそれを見積もるでしょう。以前は予期されていなかったこの追加のタスクは、ゼロラインの下のバーンダウンチャートに表示できます。これは同じ方法でリリースチャートですが、アイデアがわかります。 
このように、予想される見積もりからどれだけ燃焼したか、そしてその上にどれだけ追加したか（以下）を追跡できます。 @Bryan Oakleyが書いたように、透明性は非常に重要です。このように、スプリントごとに追加の調査結果にいくら費やすかがわかり、これに基づいて作業方法を調整します。
あなたが書いたコメントの1つに
スクラムでは、一定のフィードバックが重要です
完全にそうなのかわかりません。頻繁なフィードバックは重要ですが、状況は急速に変化しているため、顧客は常に気が変わっているため、一定のフィードバックのユーザーストーリーを使用しても決して終わらない可能性があります。 スプリントの開始時にスコープを修正してみてください。スプリントをどのように計画するか想像できません：こんにちはチーム、終了できますか今後数週間でこれらの5つのユーザーストーリーがありますが、範囲が大幅に変わる可能性があることを念頭に置いてください。奇妙に聞こえます。+-+しかし、私はあなたを間違えたのかもしれません。
あなたはスクラムをしていません。アジャイルかもしれませんが、利害関係者にスプリントを中断させる方法は、スクラムの目的を完全に無効にします。スクラムは、構築するいくつかの機能に同意し、チームがスプリントの大まかな範囲で十分であると考える方法で構築し、スプリントの最後のレビュー/デモ日に、結果を利害関係者に提示します。その時点でステークホッカーが満足していない場合、彼らの希望に応える新しいユーザーストーリーが次のスプリントに持ち込まれる可能性があります。
スクラムの目的は、期待を実現するという点であなたがどれだけうまくやっているかを測定し、その点で徐々に良くなることです。あなたがそれをしている方法は、あなたがあなたのスプリント計画を満たすために働いていないことを台無しにします、あなたはあなた自身をマイクロ管理されて、動くターゲットを追いかけます。スプリントの終わりには、自分の計画を満たすために働いていなかったため、比較するものは何もありません。
スクラムをやるふりをして、今やっているすべてのことをやめてスクラムをやっていると感じさせるか（それが無駄なので）、デモの日にレビューを保存してそこに保存するよう関係者に丁寧に頼むべきです。