Podczas pierwszej demonstracji oprogramowania w średniej wielkości projekcie, właściciel produktu identyfikuje kilka problemów, które chce rozwiązać przed udzieleniem zgody. Jak powinien zareagować kierownik projektu?

W metodykach zwinnych, takich jak Scrum, demonstracje oprogramowania (często na koniec sprintu) służą do zbierania informacji zwrotnych od właściciela produktu i interesariuszy. Identyfikacja problemów lub nowych wymagań w tym momencie jest naturalną częścią procesu. Planowanie rozwiązania tych problemów poprzez pielęgnację backlogu (backlog refinement) i włączenie ich do następnego sprintu jest standardową, elastyczną reakcją, która pozwala na ciągłe doskonalenie produktu. Pozostałe opcje są mniej odpowiednie: Kierowanie do planu zarządzania zmianami i eskalacja do komitetu sterującego jest zbyt formalne i biurokratyczne dla typowych problemów zgłaszanych w trakcie demonstracji zwinnego projektu. Odwoływanie się do dokumentu wymagań i odrzucanie zmian jest sprzeczne z duchem zwinności, która promuje adaptację do zmieniających się potrzeb. Odsuwanie rozwiązania problemów do "drugiej wersji" może prowadzić do niezadowolenia właściciela produktu i opóźniać dostarczanie wartości.