Bufor nie naprawia złej estymacji
Jeżeli zakres nie jest znany, technologia nie została sprawdzona albo kluczowa zależność pozostaje nierozwiązana, dodanie 20% nie usuwa problemu.
Duże niewiadome należy najpierw nazwać. Czasem najlepszą decyzją jest dodatkowa analiza lub discovery zamiast większego bufora.
Capacity i buffer to nie to samo
Jeżeli developer pracuje osiem godzin, ale realnie sześć godzin dziennie może poświęcić projektowi, wykorzystaj sześć godzin jako dzienną dostępność.
Brakujące dwie godziny nie są ryzykiem. To normalny sposób pracy.
Bufor powinien dotyczyć drobnych poprawek, niewielkich problemów technicznych, większego niż zwykle przełączania kontekstu, krótkich opóźnień komunikacyjnych i innych ograniczonych odchyleń.
Czy istnieje dobry procent?
Nie ma jednej wartości odpowiedniej dla każdego projektu.
- 0–5% może mieć sens przy dobrze znanej, powtarzalnej pracy.
- 10–15% może być rozsądnym punktem wyjścia przy zwykłej pracy projektowej z niewielką niepewnością.
- 20–30% sygnalizuje większą niepewność, którą warto omówić wprost.
Jeżeli potrzebujesz jeszcze większego zapasu, sprawdź, czy problemem nie jest brak informacji potrzebnych do estymacji. Te wartości są wskazówką, nie regułą.
Najwcześniejsza data i data rekomendowana
Najwcześniejszy termin wynika bezpośrednio z estymacji, dostępności i kalendarza pracy. Rekomendowany termin zawiera dodatkowy bufor.
Pokazanie obu wartości ujawnia założenie: jedna opisuje scenariusz bazowy, druga jest bezpieczniejszym punktem odniesienia do komunikacji.
Nie ukrywaj za buforem znanych działań
Jeżeli wiadomo, że klient potrzebuje pięciu dni na akceptację, zaplanuj pięć dni na akceptację. Tak samo potraktuj QA, wdrożenie, migrację danych i zewnętrzne zatwierdzenia.
Znane działania należą do planu. Bufor jest miejscem na ograniczoną niepewność, a nie na niewidoczną pracę.
Porównaj obie daty w Kalkulatorze terminu realizacji i przeczytaj, czym różni się deadline od terminu realizacji.