Chciałbym podsumować trochę wiedzę zdobytą w trakcie rozmów z trenerami Scrum na temat szacowania. Dyskusja z zespołami dostarczyły następnych ciekawych przemyśleń. A generalnie wiąże się to również z powszechnymi próbami przeliczania story pointów na dni robocze i odwrotnie. Wiadomo, że nie powinno się tak robić ale uzasadnienie i zrozumienie dlaczego jest trudniejsze.

Z punktu widzenia logiki jak i statystyki jest to jak najbardziej uzasadnione. Jeśli przeliczmy story pointy na dni to tak naprawdę przestajemy już estymować tylko dokonujemy wyceny czasochłonności. A estymaty służą do czegoś innego – ocenienia jak dużo pracy trzeba wykonać w konkretnym user story. Przecież warunki będą się zmieniać, istnieją urlopy, zwolnienia, może się zmieniać skład zespołu i tak można by wymieniać.

Żeby estymata miała sens to musi szacować pracochłonność zadania, nawet jeśli intuicyjnie próbujemy ją odnosić do czasochłonności. Dojrzalsze zespoły zaczynają to dostrzegać i nie jest już tak trudno uzyskać dobre efekty. Oczywiście może to powodować spore zmiany velocity – np. jeśli wchodzimy w obszar nowych technologi to może okazać się, że przejściowo velocity zespołu spadnie, bo pozyskiwanie umiejętności obniża wydajność.

Głębsze zastanowienie się nad tym, powoduje konkluzję, że jest to jedyny dobry sposób szacowania – inaczej mielibyśmy stałe velocity zespołu i estymaty dopasowane do bieżących warunków. Tak naprawdę każdorazowo na planningu należałoby rozważać warunki i dokonywać ponownej estymacji. Czyli wszystkie techniki związane z szacowaniem co można  dostarczyć w następnych sprintach według minimalnego, średniego i maksymalnego velocity nie miałby żadnego sensu – estymaty zrobione teraz dla zadań z następnych sprintów nie są prawidłowe. I to chyba oddaje najlepiej dlaczego nie powinniśmy tak robić – szacowanie jest i tak obarczone sporym błędem a jeśli jeszcze podczas szacowania musimy oprócz złożoności zadania uwzględnić dodatkowo przyszłe zmieniające się warunki to zaczyna przypominać rzucanie kostką. Co drastycznie obniży jakość wykonywanych estymacji.

Warto tutaj pamiętać, że velocity i szacowanie NIE jest sposobem rozliczania zespołów. To niby taka oczywista oczywistość, niestety wraca to ciągle w rozmowach zarówno powyżej zespołów jak i w zespołach. I tutaj również istnieje bardzo duże ryzyko wypaczenia estymat poprzez potraktowanie ich jako narzędzia kontrolnego zespołu. Jest to tylko i aż narzędzie do przewidywania na tyle, na ile jest to możliwe, postępu w rozwoju produktu.

Ta świadomość musi być propagowana, bo inaczej bardzo szybko doprowadzimy do sytuacji kiedy velocity i story pointy będą pasować do wszelkich narzędzi kontrolnych, tylko nijak nie będą odzwierciedlać rzeczywistości. Bo zespoły zaczną dopasowywać estymaty do tego, czego od nich się oczekuje. A nie o to chodzi.

Ja tutaj chciałbym dorzucić jeszcze, że ogromny wpływ ma również stopień „zwinności” produktu nad którym pracujemy. Jeśli nasz backlog przypomina bardziej podział na poszczególne zadania to w oczywisty sposób estymaty przestają spełniać swoją rolę. Podstawą dobrego funkcjonowania velocity jest „zwinne” podejście do wymagań. Jego brak powoduje stworzenie backlogu który jest właściwie planem projektu i velocity przestaje być użytecznym narzędziem.