Nic nie działa i nie wiadomo jak to naprawić, a jeśli już wiadomo to aby to naprawić należy poświęcić bardzo dużo czasu/zasobów.

Przerywamy sprint, przestajemy się skupiać na dowiezieniu wszystkich punktów w iteracji, stawiamy system na nogi. Wszyscy na pokład. Taka sytuacja występują tak rzadko, że nie ma sensu obudowywać tego typu zachowania w zasady Scrum’a. Nie ma sensu stosować również innych metodyk. Po prostu ratujemy się. Gdy zaczynają się zdarzać takie sytuacje często wówczas zastanawiamy się nad sensem pisania w tym projekcie nowych funkcjonalności.

Niska złożoność i wysoka dolegliwość

To błędy związane z zapuszczeniem się w dług technologiczny, które często są spowodowane niedostatecznym przetestowaniem aplikacji przed wdrożeniem na produkcję. Po wgraniu systemu wyskakują dziwne kwiatki, które trzeba jak najszybciej naprawić. Często się mówi że projekt musi się wygrzać – czyli muszą pospływać błędy od klienta, które naprawimy. Wtedy mamy sytuację z dużą ilością błędów, które nie mogą poczekać do końca iteracji.

Jeśli takich błędów pojawia się dużo wówczas zespół wyznacza wśród swoich członków zespołu dyżurnego, który zajmuje się naprawą takich zgłoszeń. W każdej iteracji lub co pół iteracji dyżurny zmienia się, tak aby ktoś nie był dyskryminowany i zdemontowany wykonywaniem czarnej roboty.

Inne rozwiązanie, które uważam, że się sprawdza to takie gdzie zakładamy pewien bufor punktów, który przeznaczamy na naprawę błędów nie wyznaczając konkretnej osoby w zespole. Scrum’owy zespół to zespół samo organizujący się. Zespół sam sobie decyduje kto dany błąd naprawi, korzystając z przyznanych punktów na tego typu zadania.

Po wyczerpaniu bufora punktów, decydujący głos ma Product Owner, który nadaje nowe priorytety pozostałym zadaniom. Wskazuje, które zadanie nie muszą być wykonane w tej iteracji na rzecz naprawy konkretnych błędów.

Nawet gdy tych błędów jest bardzo dużo tego typu podejście się sprawdza. Czarno na białym widzimy ile nowych funkcjonalności możemy w danej iteracji wykonać a ile czasu zabiera nam naprawianie błędów.

Gdy takie sytuacje są częste i uciążliwe oraz nie pozwalają na pracę zespołu zgodnie z metodyką Scrum, należy w pierwszej kolejności wziąć się za wprowadzenie poprawnych technik wytwarzania oprogramowania oraz zaprzestać zaciągać dług techniczny.

Wysoka złożoność i niska dolegliwość

Przykładem może być wyciek pamięci w aplikacji po stronie serwerowej. Wyciek ten jest stały w czasie i stopuje system raz na dwa miesiące. Wówczas jeśli specyfika działania systemu na to pozwala, można zaplanować restart tego systemu raz na miesiąc, w nocy, który trwa sekundy, podczas gdy mamy pewność, że w tym czasie nikt na tym systemie nie pracuje.

Błędy trafiają do Backlog’a i są kolejkowanie do wykonania przez Product Owner’a. Skoro jest wysoka złożoność błędu a dolegliwość jest niewielka to w danym momencie może po prostu nie opłacać się poświęcać dużo czasu na poprawę błędu. Możliwe, że są o wiele ważniejsze zadania na tą chwilę. Decyzję ma w tym przypadku właściciel produktu.

Oczywiście przykład błędu z wyciekiem pamięci musi być kiedyś naprawiony. Restart systemu jest tyko chwilowym rozwiązaniem do momentu jego naprawy, która jest precyzyjnie zaplanowana w przyszłych iteracjach.

Niska dolegliwość i niska złożoność

Jeżeli takich błędów jest niewiele, wówczas należy poprawiać je w ramach codziennej pracy programisty. Jest taka zasada, która mówi aby zostawić po sobie kod lepszym niż się zastało. Wybór błędów i ich kolejność dokonywana jest przez programistów – szkoda czasu Product Owner’a na błędy, które mają niską dolegliwość a ich naprawa jest łatwa i szybka. Jeśli tych błędów jest bardzo dużo, wówczas należy je spisać i zgrupować w paczki oraz zaplanować określoną liczbę punktów na poprawianie tego typu błędów.