回答:
理想的には、各反復後にソフトウェアにバグがなく、バグの修正が各スプリントの一部である必要があるため、ストーリーポイントを割り当てるときにバグの修正に必要な作業を考慮する必要があります（つまり、バグを生成する可能性が高いタスクは、より多くのストーリーポイントが割り当てられています）。
ただし、実際には、テストがどれほど厳格であっても、バグは展開後のすべての面で表面化します。その場合、バグの削除は別の変更であり、必要であれば機能です。このコンテキストでは、バグレポートと機能要求の間に根本的な違いはありません。どちらの場合も、アプリケーションは特定の動作を示し、ユーザー（または他の利害関係者）は変更を確認したいと思います。
ビジネスの観点から見ると、バグ修正と機能も実際には同じです。あなたがそれを行うか（シナリオB）、しないか（シナリオA）。どちらのシナリオにもコストとメリットが付加されており、まともなビジネスマンはそれらを比較検討し、利益を上げるものは何でも（ビジネス戦略に応じて長期的または短期的）得ます。
はい、すべての手段で、ストーリーポイントをバグに割り当てます。他にどのようにバグ対機能、およびバグに対するバグに優先順位を付けますか？両方の開発努力の何らかの尺度が必要であり、それは比較可能であるほうがよい。
これの最大の問題は、バグ修正の推定が難しいことが多いことです。実際の努力の90％以上は原因を見つけることにあります。見つかったら、正確な見積もりを出すことができますが、検索にかかる時間を判断することはほとんど不可能です。私は、バグの再現を試みるためにほとんどの時間を費やした、かなりの数のバグを見てきました。一方、バグの性質に応じて、推定を行う前に最小限の調査で検索を絞り込むことができます。
既に他の回答で指摘されているように、ポイントでバグを推定することは本質的に難しく、理想的な解決策は、スプリントが受け入れられた後に機能で見つかったバグを新しい機能と見なすことです。
ただし、バグのポイント推定におけるこの難しさは、アジャイルPMソフトウェアパッケージがタスクおよびバグを時間単位で推定できる多くの理由の1つです。ポイント推定に熟練するには熟練と経験が必要だからです。多くのプロジェクトでは、速度を適切に決定する際に重大な問題が発生するため、多くのアジャイルプロジェクトはポイントを使用してどのストーリーがスプリントに入るかを決定しますが、バーンダウンチャートの計算には時間を使用します。
直観に反しているように見えますが、スプリントのコミットメントを決定する際に時間の見積もりが要因として使用されていない限り、管理は可能です。過剰なコミットメントは必然的に機能の欠落や不完全、または残業につながるため、時間の経過とともにすべての関係者がポイントの推定を改善することを余儀なくされ、その時点でタスクやバグの時間を推定することは意味のないメトリックになります。
あなたはいけません、バグの解決にポイントを与えます。バグは、開発者がストーリーを完了するためのポイントをすでに獲得しているストーリーから発生するという事実を考慮してください。実際に最初にポイントを獲得するべきではなかった場合、再びポイントを受け取るべきではありません。
バグ修正は、速度に悪影響を与えるはずです。そうでない場合、品質の低下は、影響を受けないか、さらには増加した速度で報われることになります！
おそらく便利なリンク：
バグをユーザーストーリーとして扱い、いくつかのポイントを割り当てることをお勧めします。ユーザーストーリーでよくあるように、「Xとして、ZになるようにYにしたい」という形式で必ずしも書く必要はありません。 Z 'は予想される動作です」。
これの利点は、新しい機能のリクエストと並行して、バグ修正に優先順位を付けることができることです。真実は、バグを修正するよりも新しい機能の方が重要な場合があるということです。ただし、必要な作業のサイズを適切に調整することもできるため、必要な作業をスプリントに合わせることができます。
バグを修正するために必要な労力を見積もることが難しい場合があることに留意してください。相互に作用する複数のコンポーネントが関係する可能性があり、誰かがシステムの大部分の相互作用に精通するか、複数の人が修正に取り組む必要があります。
ストーリーの推定は、時間とともにチームがストーリーを解決する経験を積むという概念に基づいています。これにより、精度が向上し、速度を確立してチームの速度を測定できます。将来のスプリントの信頼できる予後を確立するための完璧な方法論。
バグは、ソフトウェア開発会社の現実です。ストーリーの開発中にバグをすべてキャッチする必要があることに同意しますが、これは常に達成できないことを受け入れ、すべてのチームが計画すべきものであるべきです。プロセスがチームを支配するべきであると頑固に考えるのではなく、逆の方向にすべきです。
もちろん、バグやストーリー、ビジネス側からは、チームが何を扱っているかは関係ありません。どちらも製品所有者に同量の価値を生み出すことができます。
私たちのチームでは、バグを推定するためのいくつかの手法を試しました。
1.を使用すると、誤って失敗しました。ほとんどのバグについて、時間の90％がバグ分析に費やされていることがわかりました。その後、バグ修正はストーリーと同じ方法で推定できます。バグをスプリントに計画することにより、未知のスコープがストーリー解決に影響を与えるというミスを犯しました。
90/10比率（バグ修正に対する分析）推定手法オプション2に基づくと、スプリント計画でカバーされたものではない分析を計画する必要がありました（オプション1から学習しましたが、実際の解決策はありませんでした）分析されたバグの対処方法）。その結果、スプリントは計画されたアイテムに集中していたため、バグ分析は行われませんでした。チームには、バックログのバグに集中する時間がありませんでした。だから最終的に彼らもやらなかった。
不確実性を受け入れることで、オプション3を決定しました。製品のバックログを、ストーリーポイントとバグバックログを使用してチームが推定できる通常のストーリー/タスクパーツに分割しました。バグバックログでは、製品の所有者はビジネス価値と非常に大まかなチーム判断に基づいてバグをランク付けします。チームは、スプリント中に、バグに集中するために費やすことができる時間を割り当てることができます。とにかくそれを計画することは不可能だったため、製品所有者は正確な結果を知りません。バグバックログと通常のバックログの比率は、各バックログの現在のステータスと、コンテンツの重要性とビジネス価値に応じて、スプリントごとに調整できます。
不確実性を取り除くことで、チームは再び解放されました。スプリントは未知のバグによって侵害されませんでした。バグを別のバックログに分離することで、チームの通常のスプリントへの集中力を高め、重要なビジネス価値を含むバグを完成させました。
ストーリーポイントがあなたに適しているかどうかによって異なります。最初にストーリーポイントを使用してバグを推定しようとします。それが失敗した場合、私のオプション3を試してください。これにより、私たち（30スプリント以上）のチームは、大きなビジネス価値を含む古いバグに再び焦点を合わせました。また、チームが単に見積もることができないものを提供しようとすることから解放されました。バグ修正によりビジネス価値の大きな部分（バグとストーリーの比率に基づく）を提供しながら、現実に近づき、スプリントを再び成功させた未知の要素を受け入れていました。最近使用した比率は50/50でした。
ストーリーポイントをバグに割り当てる際の一番の答えには同意しません。ストーリーポイントは、新しい価値を提供するためのものです。製品の価値と価値のないアイテムにポイントを割り当てる場合は、時間を見積もって追跡することもできます。
バグは昨日やったことのオーバーヘッドであり、製品の完成速度を示すものではなく、新しい製品の価値も生み出しません（考えてみてください）。バグは、割り込みや、毎週対処する必要がある他のすべてのカウパイのようなものです。ストーリーポイントの全体的な考え方は、製品（または機能セット）を提供する時期を追跡/推定することです。ストーリーポイントはarbitrary意的であり、それが評価からすべての非価値オーバーヘッドを除去する方法です。一般的に、価値のない仕事は週ごとに一定であるため、チームの速度に組み込まれています。この価値のない作業を削除または削減すると、チームは加速します。
別の言い方をすれば、なぜバグのポイントを追跡するのでしょうか？それで、一日の終わりに、各メンバーがどれだけの「仕事」をしたかを知ることができますか？それを停止する！悪いマネージャー！:)プレーヤーではなくチームを測定します。1人の人が体重を落としていない場合は、自分で管理するようにチームを奨励します。はるかに効果的です。ストーリーポイントアイテムを行うことで個人の気分が良くなることはありませんが、スプリントの最後にコミットメントを行うと、チーム全体が気分が良くなるはずです。スポーツでは、目標はチームにとっても個人にとっても良いものですか？個人が自分のためにプレーする場合、チームは長期的に負けます。
最終的には、ポイントをまったく使用しないことを望みます。推定は、実際の作業から奪われる時間です。チームが最大カイに達したとき、彼らはポイントをまったく使用せず、スプリントに引き込むことができるアイテムの数を正確に知っています。彼らは、見積もりがプロセスの無駄である作業単位を分割する技術を習得しました。
一部のタスクは推定可能ですが、一部はそうではありません。 推定できないものについては、予算を使用します。
欠陥の修正は、未知のコンポーネントがいくつかあるため、容易に推定できるタスクではありません。欠陥の原因は何ですか？原因を理解したら、どのように修正できますか？この変更はシステムの他の部分にどのような影響を与えますか？この欠陥の修正を注入した新しい欠陥はいくつありますか？
欠陥の原因は、ソフトウェアライフサイクルのどの時点からでも発生する可能性があることに注意してください-誤解または誤解された要件、貧弱な設計または誤った前提、貧弱なコーディング、不適切なテスト、現在のリリースから学んだ情報に基づく問題に関する新しい知識...
予算の作成は、バグ修正タスクのいくつかの異なる方法で実行できます。ここに、私が効果的に使用したアイデアをいくつか示します。
目標は、割り当てられた予算内でできるだけ多くの欠陥を修正することです。報告された欠陥に優先順位を付けるための顧客戦略について話し合います。たとえば、重大度、優先度の順に欠陥を並べ替えますか？完全優先？最初に「ぶら下がっている果物」を攻撃する必要がありますか？UIのバグが最初ですか？
また、バグを修正しても価値はありません。欠陥を修正することは無駄の一種です。この機能で既に価値を獲得しているので、バグを修正するための「ボーナスポイント」を取得しないでください。
予算があると、計画に役立ちますが、Velocityの正確な全体像が得られます。バグ修正のために特定の数のポイントを割り当て、履歴データに基づいておおよその時間を割り当て、予算内でできるだけ多くのバグを押しつぶします！
ストーリーやバグ、雑用、それぞれのポイントに焦点を当てるのではなく、顧客に機能を提供することに焦点を当てる方が良いと思います。
顧客はソフトウェアが機能することを期待し、これらがビジネスを前進させるため、開発、拡張、および新機能に真の価値を与えるだけです。
バグの修正は、重要な場合もありますが、ビジネスを新しい分野や新しい顧客に押しやることはありません（接線上および最終的にはそうかもしれませんが、経営陣が測定しているのはすぐではありません）。
そのため、ポイントは、速度の高い視点と、同様にスコア付けされたストーリーに対して過去に何ポイントが行われたかという観点から最もよく表示されます。
これにより、今週のストーリーを完成させ、頻繁にストーリーが完成していないことを頻繁に発見する必要性を押し進めるのではなく、実績の履歴による管理につながる可能性があります。ただし、事前の制御が失われ、これが必要とする信頼が高まると、何人かのマネージャーが恐怖の扉に向かって走ります。
私はPivotal Tracker（私はJIRA、Trak、Trelloなども使用しています）を使用しますが、Pivotal Trackerは雑用やバグのポイントも行いません。これは、JIRAでもあなた自身が見ているように、上記と同じ理由で行われています。