Realizacja w połowie czasu jest ogromną różnicą w stosunku do szacunków. Dla mnie oznaczałoby to znaczne ryzyko, że to, co faktycznie zrobił twój zespół, odbiega od oczekiwań użytkowników na początku sprintu. Ponadto Sprint ma również zapewniać wystarczającą funkcjonalność, aby nadszedł czas na nowe opinie od PO.
Ryzyko związane z odebraniem rzeczy z górnej części PB i kontynuowaniem jest takie, że te elementy z górnej części PB są nieaktualne (zarówno pod względem treści, jak i priorytetu), i że Twój zespół popełnił błąd w ostatnim sprincie i będziesz po prostu opierać się na tych błędach, nie otrzymując opinii od PO.
Powiedziałbym, że najbardziej rozsądnym działaniem jest wezwanie Sprint do wykonania, wstrzymanie zwykłego zakończenia przeglądu Sprint, planowanie spotkania i retrospekcja i rozpoczęcie następnego Sprint.
Jeśli chodzi o wykresy wypalenia, oryginalne pytanie wydaje się nie mieć sensu, po co jest. To naprawdę tylko narzędzie do ustalenia, czy masz problem z postępem podczas sprintu. Zgodnie z tym, co zostało opisane, tabela wypalenia powinna była zostać zastosowana w tej sytuacji około 2 lub 3 dnia Sprintu, gdy pokazałoby to, że Drużyna była znacznie wyprzedzająca harmonogram zadań Sprint. Następnie zadajesz pytanie „Dlaczego?” I określasz, czy twoje prognozy były po prostu dalekie, czy może programiści źle interpretują zadania, czy też coś w jakiś sposób znika z szyn.
Ale kiedy zignorujesz tabelę wypalenia i zaczniesz płynąć dalej, jakby nie działo się nic dziwnego, wtedy wygląda na to, że traktujesz ją jak jakiś bezsensowny artefakt, który produkujesz, ponieważ „książka” ci to nakazuje. Moim zdaniem, jeśli zdecydujesz się po prostu ściągnąć trochę więcej rzeczy z górnej części PB i kontynuować przez drugi tydzień, to po prostu rozpocznij nową wypalanie na drugi tydzień (i wtedy możesz zignorować, jakbyś zrobił to dla pierwszy tydzień).
