既存のプロジェクトをスクラムに移行される際によく直面するのが、スクラムを開始するより前から存在する未修正のバグのバックログである。こうしたバグのバックログをどうやって減らすのがもっともよい方法なのだろうか？ Mike Cohn氏はこれらの古いバグにストーリーポイントを割り当て、通常のスクラムワークフローを用いて各スプリントでそれらを優先順位付けすることをすすめている。
私が一般にお勧めするのは、バグ修正にポイントを割り当てることです。 [...] チームが実際にどれくらいの作業を仕上げたのかを見ることができるだけでなく、その履歴データも見ることができますし、各スプリントでどれくらいの作業がバグ修正ストーリーに投入されたのかを知ることもできます。このことを知ることはチームやプロダクトオーナーにとって役に立つことです。例えば、プロダクトオーナーがあるリリースに価値ある別の機能を追加するために、今後6つのスプリントでバグフィックスを行わないことを検討する、という状況を想像してみて下さい。もしチームのこれまでの平均速度が25ポイントであり、各スプリントで5ポイントがバグ修正に使われていると分かっていれば、今後6スプリントでバグ修正を取りやめることによって、新しい機能の開発に30（6*5）ポイント多く利用できるといことがわかるでしょう。
Mike Cohn氏によってすすめられているスプリントの優先付け戦略にくわえ、Charles Bradley氏も開発チームがスプリントの中でバグを修正することに対するより多くの選択肢を求めている。
[...]確かにプロダクトオーナーはバグをスプリント内で優先づけることができますが、開発チームも（バグがバックログにあるかどうかによらず）バグを修正する必要があると考えるバグを選ぶことができ、それをスプリントにタスクとして持ち込むことができます（バグがバックログにあるかどうかによらずこれに対するストーリーポイント、ヴェロシティポイントを得ない）。 開発チームのみがプロダクトバックログをどの程度スプリントに取り込むかを決めることができ、もし50%程度をスプリントのプロダクトオーナーによって優先付けら得ていないバグ修正作業に使うと決めたなら、その通りになるべきでしょう。しかし、その状況はヴェロシティが低くなることで観察できるでしょう。
Jack Milunsky氏は昔からあるバグをどう扱うかと、現在のスプリント内で埋め込まれたバグとの間に重要な区別をしている。
バグにストーリーポイントを割り当てるべきなのは、それが昔からあるバグの場合のみです。これはプロダクトオーナーにとって明確な意味があります—特にこの場合は品質においてです。スプリントの間に見つけられ修正されたバグにはストーリーポイントを割り当てるべきではありません。それは、チームがどのくらいの速度で活動しているかを測るのに間違った感覚を与えてしまうようなヴェロシティへの影響があるからです。
スクラムのルールの下でつくられたが、何らかの理由でそのスプリントの境界から逃れてしまったバグを修正するためにストーリーポイントを割り当てるべきだろうか？ すなわち、以前のスプリントで"done"と宣言されたユーザストーリーで見つかったバグについてはどうすべきだろうか？ Ron Jeffries氏は次のように書いている。
もしどういうわけかストーリーが漏れて欠陥が見つかってしまったら、そのストーリーは既にヴェロシティに記録されているものです。ヴェロシティは人為的に高くなっています。では何をすべきでしょうか？ 一つの可能性は、その量だけプログレスバーを小さくし、それを修正する時に、そのストーリーを挿入し直すことです。このやり方は正確かもしれませんが、その必要はありません。その代わりにすべき唯一のことは、次回終了するストーリーだけを数えることです。欠陥のあるストーリーを修正するのに費やした時間はカウントしません。進捗ラインは１ストーリー分だけ減り、再開します。ラインはしばらくの間人為的に高かったかもしれませんが、その時点で適正に戻っています。
欠陥にかかる時間は間違ったストーリーを構築するより少ないかもしれないし、多いかもしれません。どちらの場合でも、ストーリーを正しく完成させるのに必要な時間や完了したストーリーの数はこのストーリーに関しては釣り合った形に戻ります。見積もりは必要なく、明らかに無駄なものを扱うべき理由をあたかもそれが何かよいことであるかのように無理に説明する必要もないのです。