過去、バグ修正をベロシティに加えるべきか多くの議論や論争があった。「１つの」正しい答えは、なさそうである。しかしアジャイラには、どのような状況でバグ修正を追加すべきか、どのように追加すべきか、どこで追加しなくてよいかを提案している人達がいる。
Syed氏は、加えるか、加えないかは ベロシティをどう分類するかに依存する、と言っている。もしベロシティが「価値視点」なら、バグ修正は加えられるべきでない。顧客に何も価値を追加していないからである。しかし、もしベロシティが「コスト視点」なら、バグはベロシティに含まれるべきである。修正に時間と労力がかかっているからである。
Mike Cohn氏は、バグにストーリーポイントを割り当てるべきである、と言っている。氏によれば、
こうすることで両方の世界に最善なことを達成できます。我々はチームが実際どれだけの仕事を成し遂げたかがわかりますし、履歴データも取れますし、各スプリントでどれだけバグ修正ストーリーに時間が取られていたかがわかります。
Jason Yip氏は、面白い比喩を使って、メーターとしてのベロシティを最後にあるゴールに向かってフィールドを走る 場合と較べている。氏は、ここで重要なのはゴールに向かっていることだ、と強調する。
今もし誰かが前進を5m逆方向に進めたら、ベロシティは減る。ベロシティはスカラー量ではなくベクターだからである。
Robert氏は、ベロシティを決めるのに 複式簿記のやり方 を勧める。氏によると、
私はベロシティにバグ修正を加えたいです。しかし複式簿記の古典的なやり方によってです。 私はまた、バグが作られた、もっと前のイテレーションからこの種のベロシティを考慮したいです。それをこのイテレーションへのマイナスのオーバーヘッドとして、カウントします。
Greg氏は、 ベロシティにバグを入れない、と一律に決めるのは危険だ、と言う。入れるか入れないかは、コンテキストと目標の実際の定義に依存するべきだ。
恐らく目的は新しいフィーチャです。恐らく目標は多くの顧客が興奮するような1つのフィーチャを作ることです。恐らく、目標はレガシー製品のバグを修正することです。ベロシティにバグを含めないことにするのは、チーム内では上手くいくでしょうが、意味をなさないコンテキストがたくさんあります。
Jack Milunsky氏は、ベロシティにバグ修正を追加することになるかどうかに関わらず、修正に時間がかかっているので、バグは考慮されるべき である、と言っている。
スプリント計画会議で、バグはユーザーストーリーと一緒にスプリントやイテレーションに計画されるべきです。 タスクの実装やバグ修正の合計時間はチームにために決めた利用可能なキャパを超えるべきではありません。私は、多くのコーチがバグは、別けて追跡されるべきで、スプリントで見つかったバグは処理されるべきだ、と言っているのを知っています。しかし、実際のところ、これは必ずしも実際的ではありません。試してみてください、チームの予見性が格段に改善します。
こうして、バグを考慮することには、多くの人が合意している。バグ修正をベロシティに追加すべきかは、意見の別れる問題で、恐らくそうなるのは当然であり、状況による。