Długie i czasochłonne szacowanie zabija zwinną wycenę. Zamiast podejść do sprawy sprawnie, zamieniamy sesję wyceny w niekończące się dyskusje. Po co?
„Ten proces jest kosztowny”
A my znów o szacowaniu wymagań. Wynika to między innymi faktu, że pracujemy nad książką, która dotyka tego właśnie obszaru. Równie pomocny był też jeden z komentarzy, który znalazł się pod filmem o konieczności szacowania elementów Backlogu? Zastanawialiście się kiedyś nad przyczynami sytuacji, w których wycena elementów zamienia się w długie szacowanie, zajmujące więcej niż przysłowiową chwilę?
Jeśli estymacja elementów Backlogu Produktu zajmuje Ci za dużo czasu to wiedz, że robisz coś źle. Jeszcze nie wiem co, ale zaraz wspólnie z Tobą postaram się znaleźć kilka przyczyn potencjalnych problemów.
Zacznijmy od tego, co to znaczy długie szacowanie? Trudno podać konkretny czas, mogę jedynie porównać się do praktyki. Wspólnie z Tomkiem posiadamy doświadczenie pokazujące, że w przypadku doświadczonych zespołów listę wymagań składającą się z około 100 elementów da się spokojnie wycenić w półtorej do dwóch godzin. Czy to dużo?
Patrząc przez pryzmat wyników tego procesu, może się wydawać, że tak. Weźmy miesięczną pensję każdego z Deweloperów, podzielmy ją przez 80, zsumujmy i voila, oto bezwzględny koszt tego procesu. Procesu, który nie przyczynia się znacząco do powstania Produktu. Pisząc „znacząco” mam na myśli fakt, że z samego faktu wyceniania praca się nie zrobi. Umożliwiamy jej zaprognozowanie, jednak od prognozy wciąż daleka droga do działającego, potencjalnie wdrażalnego przyrostu.
’Właściwie to po co?”
Nie dziwi więc fakt, że coraz więcej Deweloperów głośno pyta „Po co?”. Pytanie to pada nie tylko od członków Scrum Team. Często to sami Managerowie o to pytają. Czy jest to nam naprawdę potrzebne?
Z jednej strony doskonale ich rozumiem. Szacowanie to praca, którą robimy, umówmy się, mocno „na czuja”. Odrywa nas to też od najważniejszego – przekształcenia wymagań w działający Produkt. Z drugiej strony, widzę naprawdę realny wpływ dokonanego oszacowania i to nawet w przypadku, gdy podczas Planowania Sprintu część tych wycen ulegnie zmianie. Ot, skutek zmieniającego się Świata.
A może tak rzucić to wszystko, i… przestać szacować? Właśnie to założenie jest podwaliną ruchu #noestimates, które jednak nie do końca mówi „nie szacujcie”. O tym jednak poopowiadamy kiedy indziej. Na teraz, skupmy się na tym, żeby zanim podejmiemy jakąś decyzję przekazać najpierw wiedzę pod tytułem „Po co to robimy?”. To oczywiście robota Scrum Mastera, który jeśli widzi problem opisany powyżej, powinien zareagować. Może jeśli spędzi chwilę nad wytłumaczeniem przyczyny, pojawi się naturalna chęć do wyceny?
Wiadomo, że efektywniej robimy te rzeczy, które rozumiemy. A jeszcze bardziej, jeżeli wiemy, że nam się przydają.
Czasochłonne szacowanie
Czasochłonne szacowanie, takie naprawdę długie, to zmora i główna przyczyna faktu, że Zespoły wyceniać nie chcą. Ile można gadać i spierać się nad wyceną wymagania? „Rzućmy 13 Story Points, też będzie dobrze„, „Ile byśmy nie dali i tak będą to challenge’ować„. Te i inne głosy na pewno często słyszycie w swoich Zespołach. Niemające limitu dyskusje, czasem kłótnie, wszystko to psuje atmosferę tego procesu, który powinien być… szybki.
Wskazując przyczyny tego stanu rzeczy jednym ciągiem mógłbym wymienić: presję czasu, brak wpływu na cokolwiek, brak zrozumienia procesu i korzyści z szacowania czy brak zrozumienia technik szacowania. Czy wymieniłem wszystkie? Nie, ale wymieniłem te najważniejsze, te, które mają bezpośredni wpływ na to, że wycena jest kulą u nogi niejednego PO czy SM. Od tej kuli zaczynają się zresztą tzw. wyceny eksperckie PO czy brak wpływu Zespołu na ilość planowanej w Sprincie pracy. Sami to sobie robimy!
Ktoś może mi tu zarzucić w brak jasnego wskazania przyczyn, a przecież zobligowałem się do pomocy. Rzućmy zatem okiem na dwie z wyżej wymienionych – brak zrozumienia procesu i korzyści i brak wpływu na cokolwiek. O presji czasu („obiecałem wycenę na wczoraj„) i braku zrozumienia technik pisać nie muszę (patrz: Planning Poker – robisz to źle na naszym kanale na Youtube).
Co z tymi przyczynami?
Dwie z podanych przeze mnie powyżej czterech już omówiliśmy. Zostają jeszcze dwie, brak zrozumienia procesu i korzyści, które stoją za procesem szacowania elementów. Zajmijmy się teraz pierwszą z nich.
Wycena jest potrzebna PO, musi on na bieżąco aktualizować swoje szacunki, interesariuszom, na podstawie widzialnego Backlogu będą podejmowali decyzję co do kolejności realizacji. Jest ona też potrzebna samemu Zespołowi. Przecież to oni właśnie wykorzystają estymaty do planowania. Tyle korzyści i to z jednego zwinnego elementu! Czy na pewno powiedzieliście o tym swoim Zespołom? Czy oni to czują?
Brak wpływu na cokolwiek to konsekwencja ignorowania wycen. Jeśli członkowie naszego Zespołu widzą, że napracowali się w pocie czoła, a to i tak nie jest nigdzie wykorzystywane po co mają to robić? Najprostszy przykład, proszę bardzo:
„Średnie Velocity z 5 ostatnich Sprintów wynosi 20 Story Points. Zespół zaplanowała się na 21. Product Owner zdecydował, że Zespół musi wziąć jeszcze 2 kolejne Story, bo muszą być zrobione.”
To wzorzec sytuacji, która ma miejsce w wielu organizacjach. Po co mamy szacować, śledzić Velocity, planować z uwzględnieniem historycznych danych, skoro nie ma to wpływu na moją realną pracę? Możemy wręcz zapytać, co będziemy z tego mieli? Czy czas poświęcony na wycenę w ogóle się zwróci?
Szybka wycena
Estymacja elementów Backlogu powinna angażować wszystkich członków naszego Zespołu. Jeśli trwa długo, sami generujemy sytuację, w której część ludzi się wyłącza, a to znacząco wpływa na efektywność tego procesu. To dwa kroki: szybka dyskusja nad wymaganiem w celu wypracowania jednego zrozumienia, a potem wycena przy wykorzystaniu wybranej techniki. To jest prawidłowy schemat działania zwinnych Deweloperów. Jak uzyskać to zaangażowanie? Odpowiedź znajduje się powyżej.
Jeśli zadbamy o to, żeby wycena nie była jedynie obowiązkiem, a miała dalsze (pozytywne) skutki w życiu Zespołu będzie ona wyglądała tak jak powinna, będzie szybka. I o to może zadbać zarówno Scrum Master, jak i każda inna osoba.
Przytoczony na początku mojego wpisu czas estymacji około 100-elementowego Backlogu jest jak najbardziej prawdziwy. Da się to zrobić w 1,5 do dwóch godzin. Oczywiście, były to zespoły, które miały w szacowaniu doświadczenie, a temat, który podlegał estymacji nie był dla nich nowością. Ale przede wszystkim – wszyscy wiedzieli, po co szacują i jak później wykorzystają te dane.
Podzielcie się swoim doświadczeniem, napiszcie w komentarzach jak to wygląda w miejscach, w których macie możliwość obserwacji procesu.
