Benjamin Franklin, pisząc w liście do Jean-Baptiste Le Roya, że na świecie pewne są tylko śmierć i podatki, nie mógł z pewnością przewidzieć, jak wiele osób wejdzie w polemikę z jego stwierdzeniem. Ja również pozwolę sobie na krótkie sprostowanie. W życiu developera nie ma bardziej pewnej a zarazem codziennej rzeczy, jak błąd oprogramowania.
Jeszcze zanim zaczęto opracowywać zwinne metodologie wytwarzania oprogramowania, zarządzanie defektami, zwanymi potocznie „bugami”, odbywało się dopiero po fazie implementacji. Rozsynchronizowana praca pomiędzy pisaniem kodu a sprawdzaniem jego jakości być może przynosiła korzyści związane z utrzymaniem harmonogramu, jednak naprzemienne testowanie i naprawianie powodowało nienaturalną przerwę na różnych etapach projektu. Samo estymowanie i priorytetyzacja rzeczy do naprawienia nie stanowiły wielkiej trudności, jednak nagromadzenie się w czasie ogromnej liczby scenariuszy, przypadków testowych i wymagań powodowały duże rozwarstwienie spójności zgłaszanych defektów. Często przekładało się to na zaciemniony obraz przestrzeni, którą trzeba było usprawnić.
By nie powielać błędów metodologii kaskadowych, zwinne podejście powinno implementować wspólną politykę postępowania, dotyczącą obserwacji i zgłoszeń poczynionych przez osoby odpowiedzialne za testowanie oprogramowania. I tak, pewien zbiór reguł jest potrzebny. Przy niewielkich projektach pozwala to zaoszczędzić czas dyskusji na temat każdego, pojedynczego defektu. Projektom większym, korporacyjnym, dodatkowo będzie on służyć jako punkt odniesienia w rozmowach z osobą zarządzającą obszarem bugów.
Jednym z najpopularniejszych sposobów określania priorytetu konkretnego błędu jest podejście matrycowe. W swojej najprostszej wersji agreguje ona dwie, kluczowe dla określenia istotności defektu, informacje: prawdopodobieństwo jego wystąpienia (likelihood) oraz negatywny wpływ (zwany niekiedy dotkliwością, stąd severity), jaki wywrze na system. Każdej dziedzinie można przyporządkować numeryczny zbiór wartości, zwyczajowo przyjmując, że najmniej prawdopodobnym oraz najmniej dotkliwym błędom przypiszemy wartość równą jeden, a błędom z drugiej strony skali – wartość równą pięć. Z każdego rozpatrzonego argumentu otrzymany zostanie iloczyn wartości, który pomoże w uszeregowaniu defektów pod kątem ich ważności.
Po ustaleniu priorytetów, błędy najlepiej jest traktować jako zwykłą część backlogu. W konfiguracji zwinnej sukcesywne wplatanie ich w Sprint Backlog, pozwoli na ich płynne rozwiązywanie bez okresów tak zwanego firefightingu, czyli zintensyfikowanej pracy wyłącznie nad rozwiązywaniem bugów. Nie należy się jednak porywać z motyką na słońce – polityka „zera defektów” jest pojęciem wyłącznie wirtualnym i należy traktować je wyłącznie jako wskazanie celu firmy, by zidentyfikowanych błędów było jak najmniej.