Kiedy to ma znaczenie
Developer odkrywa nieudokumentowaną integrację, projekt zmienia się po refinementcie albo ważne założenie okazuje się fałszywe. Trzymanie się starej liczby nie chroni planu. Ponowna estymacja ma sens, gdy zmiana wpływa na capacity, koszt lub termin.
Praktyczny sposób działania
- Zapisz pierwotny zakres, poziom pewności i założenia. Bez punktu odniesienia trudno wyjaśnić zmianę.
- Oddziel nowy zakres od nowej wiedzy o dotychczasowym zakresie. Nowa funkcja wymaga osobnej estymacji; odkryta zależność zmienia wcześniejszą.
- Oszacuj pracę pozostałą do końca. Wykonaną już pracę pokaż osobno, aby nie ukryć postępu.
- Przedstaw nowy zakres, wartość do planowania i wpływ na zależne zadania. Ustal, kto akceptuje zmianę zakresu lub terminu.
Przykład
Ticket miał 8–12 godzin przy założeniu, że istniejące API udostępnia status klienta. Po czterech godzinach zespół odkrywa potrzebę nowego endpointu i przeglądu uprawnień. Pozostałą pracę ocenia na 10–16 godzin. Raportuje cztery godziny wykonane, nowy zakres oraz decyzję dotyczącą API. Nie podmienia po cichu pierwotnych 8–12 godzin.
Podejmij kolejną decyzję
Wracaj do estymacji po istotnym odkryciu, nie po każdej drobnej przerwie. Przy niskiej pewności ogranicz czas krótkiego rozpoznania i umów kolejną ocenę. Pierwotna liczba pozostaje śladem wiedzy zespołu. Narzędzie pomoże przygotować nowy zakres dla potwierdzonej pracy.