スプリントでのトラブルシューティングの計画
時々、再現が難しい難しい問題に直面します。このような問題を解決するための計画を作成することは、（ほぼ）元に戻すことはできません。
現在私たちがしていることは、これらを分析/再現で分割し、問題を解決することです。何も知らない限り、結果ではなく努力によってこれらの時間を調査し、予約するために何時間も計画しています。
これは真のアジャイルスプリントのようには感じられません。この状況を改善する方法について何か提案はありますか？
ITILは、問題とインシデントを区別することで、この問題をうまく理解していると思います。インシデントを修正することはできません...誰かがそのインシデントの背後にある問題を調査して把握する必要があります。物事を見るその方法には一定のオーバーヘッドがありますが、プロジェクトの範囲が拡大するにつれて、さまざまな方法で役立ちます。
それはあなたがしていることとほとんど同じだと思います。 gnatが投稿したリンクされた質問を読んでいませんが、インシデントはスプリントに属していないと思います。最初に問題のステータスに到達する必要があります。つまり、原因を把握し、問題の解決策を提案する必要があります。
場合によっては、障害バックログが適切な場所である可能性がありますが、...障害が（明確さの欠如ではなく）責任を負い、製品の所有者（？私は？）が取り組む（または誰かに取り組む）ことができる場合。
アジャイルでは、 スパイク という用語があります。ここでは、ストーリーの見積もりを行うために、問題の調査に時間を費やします（通常は私の経験では修正されています）。あなたの場合、スクラムを実行していて、バグのタスクの見積もりを取得しようとしている場合は、残りの作業を見積もることができるように、（実行しているように）スパイクを実行する必要があります。
これらのスパイクは、優先順位付けにも使用できます。スパイクが問題が発生する可能性が低いこと、非常に特定のハードウェアシナリオでのみ発生すること、または「Y」で終わる月の第2火曜日にのみ発生することを発見した場合、このバグのバックログの優先度を下げることを決定できます。
そうは言っても、バグの場合、私は通常これを行いません。私はスプリントに「x」のバグを取り込んで、作業中の通常のストーリーのグループと一緒に優先順位に従ってチームに作業させる傾向があります。その作業中に優先順位に影響を与える可能性のある情報を発見した場合は、それに基づいて行動します。