"Zajmie ile zajmie"
To nie tylko wygodna estymacja, ale też jedyna uczciwa.
Każdy programista (ale niewielu nie-programistów) wie, jak złożonym procesem jest programowanie. Zbyt złożonym, żeby dało się precyzyjnie z góry określić potrzebny czas na wykonanie zadania.
Precyzja w estymacji jest dla mnie wręcz niepokojąca. O czym może ona świadczyć?
- robisz coś banalnego
- masz niskie DoD - np. brak refactoringu na bieżąco
- negocjujesz scope z pozycji siły - np. pozwalasz na błędy, byle zmieścić się w estymacji
Story Points (SP)?
Lepiej, ale to rozwiązanie ma wciąż dużo wad:
- zadziwiająco trudno jest wyplenić szkodliwą technikę: estymowanie w czasie tłumaczone na SP
- im więcej SP tym większa wariancja
- SP >1 sygnalizuje, że task można rozbić na mniejsze. Czyli wcześniej dowieść jakąś część. Dlaczego tego nie zrobić, skoro leży to w istotcie zwinności?
- SP to wciąż jest tylko estymacja. Reality check będzie brutalny
Alternatywy
Biznes nie potrzebuje estymacji. Biznes potrzebuje przewidywalności.
Przewidywalną alternatywą dla estymacji jest forecast. Liczymy ile tasków udało się dowieźć (całych!) w trakcie sprintu. I to jest nasze velocity.
Technika ta sprawdzi się tylko w przypadku tasków rozbitych na SP=1.
Wniosek? Brutanie zwinny programista rozbija taski na SP = 1.