Brak informacji zwrotnej od klienta:
Jednym z powodów stosowania metodologii Scrum, jest otrzymywanie feedbacku od klienta. Wracając do analogii domu, klient powinien wiedzieć na wczesnym etapie prac, gdzie będą drzwi. Pokazujemy mu to nie wstawiając drzwi w kilku miejscach, tylko na planie. Największy problem powstaje wtedy, gdy dom jest już otynkowany, ale klient przypomina sobie, że chce przenieść całkowicie jedną ze ścian i wstawić w niej drzwi, bo obecne mu nie odpowiadają.
Niestety, ale w projektach programistycznych dzieje się podobnie. Zwykle aplikacja jest wydawana regularnie co jakiś czas, jednak feedback zbierany jest podczas jednego testu akceptacyjnego. W takiej sytuacji klient zwykle znajduje kilkadziesiąt rzeczy, które powinny działać w jego odczuciu inaczej. Jeśli są to drobne zmiany, można uniknąć crunchu. Jeśli dotykają one głównych elementów działania aplikacji, mogą wiązać się z koniecznością usuwania starego kodu i tworzenia rozwiązań od nowa. Powoduje to frustrację, nieufność i siedzenie po godzinach.
Rozwiązaniem jest zbieranie feedbacku od klienta jak najwcześniej i regularne reagowanie na zmiany. Dzięki temu będziemy wiedzieli także, w jaki sposób tworzyć nowe elementy i unikniemy wielu błędów. Błędy logiczne w działaniu aplikacji odkryte na etapie analizy są wielokrotnie mniej kosztowne w naprawie niż te, które zostaną znalezione na produkcji.
Jeśli dopiero po pokazaniu gotowej aplikacji klientowi dostajemy feedback, że działa ona inaczej, niż on oczekuje, jest to oznaka błędów w zbieraniu wymagań i ogólnie, analizy aplikacji. Dodatkowe godziny spędzane przez programistów nie rozwiążą tego problemu.