Szacowanie w Scrum

Story Points, czyli „szacowanie w punktach” to temat od którego nie da się uciec, szczególnie kiedy rozmawiamy o jakimkolwiek podejściu zwinnym. I chociaż nie są one elementem Scruma, to na dobre zagościła w scrumowych okolicach.

Od 2020 roku Scrum wcale nie mówi, że wymagania czyli Elementy Backlogu Produktu muszą być oszacowane. Podręcznik mówi, że zwykle posiadają one określoną wielkość (rozmiar). Wcześniej było powiedziane wprost, że PBI-ki muszą być oszacowane.

Wielkość poszczególnych wymagań potrzebna jest nam głównie, o ile nie wyłącznie, do planowania kolejnych Sprintów. Chcemy wiedzieć, ile pracy możemy zmieścić w kolejnym Sprincie. Do tego wypadałoby wiedzieć jak duże są poszczególne wymagania i ile mniej więcej pracy będą wymagały od całego zespołu. No i oczywiście warto byłoby znać nasze Velocity, czyli prędkość.

Kluczowe są tutaj dwie kwestie. Po pierwsze, nie szacujemy poszczególnych zadań, które składają się na realizację jakiegoś wymagania, ale całe wymagania, czyli PBI. Po drugie, szacujemy potrzebną pracę całego zespołu. Nie patrzymy indywidualnie na to, ile poszczególnym członkom zespołu zajmą poszczególne taski. Nie znamy przecież wszystkich czynności, które będzie trzeba wykonać. Nie powinniśmy też wiedzieć, które osoby będą realizowały które zadania. Scrum jest metodyką zespołową i to zespół jest tutaj dla nas punktem wyjścia, a nie poszczególne indywidualności.

Tak więc chcemy wiedzieć, czy poszczególne elementy Backlogu Produktu są duże czy małe i chcielibyśmy też potrafić jakoś przyłożyć do naszych typowych dokonań w jednej iteracji. To nam pozwoli lepiej się zaplanować, a Product Ownerowi – cokolwiek prognozować.

Czym są Story Points?

Stary Points, czyli popularne „punkty” to system oceny złożoności i pracochłonności wymagań. Jest to miara względna, która ujmuje nie tylko sam czas, ale także rzeczy jak złożoność, zmienność wymagań, niepewność czy ryzyko.

Tu warto podkreślić, że faktycznie mówimy o wymaganiach, czyli o czymś bardziej skomplikowanym niż tylko i wyłącznie „zadanie do zrobienia”. Te ostatnie (taski) najczęściej będziemy szacować w godzinach. Proste rzeczy z pewną dozą dokładności jesteśmy w stanie oszacować w miarę precyzyjnie, szczególnie jeśli są powtarzalne. Natomiast jeżeli chodzi o skomplikowane tematy, całe wymagania ipotrzeby biznesowe, to jest już z tym o wiele trudniej.

Wiemy, że przygotowania jakiegoś posiłku, czyli na przykład zrobienie schabowego, którego wiem jak zrobić, zajmie nam określony czas. Natomiast w przypadku rzeczy bardziej abstrakcyjnie zdefiniowanej – jako potrzeba, a nie konkretne zadanie – ten czas jest o wiele trudniejszy do uchwycenia. Dla przykładu, jeżeli umiemy gotować to jesteśmy w stanie oszacować, ile zajmie nam przygotowanie jednego obiadu. Niech to nawet będzie ten schabowy z ziemniakami i mizerią. Ale przy bardziej abstrakcyjnym przykładzie, „chciałbym nauczyć się jak robić samodzielnie makaron”, trudniej jest dać konkretną wartość godzinową.

Tu z pomocą idzie nam porównywanie wymagań między sobą. Jeżeli wiem, jak długo zajęła mi nauka robienia pierogów albo pieczenia ciasta albo czegokolwiek innego, to jestem w stanie estymować (a nie dokładnie określić) ile czasu zajmie mi zdobycie podobnej umiejętności. Cały trick Story Points polega na tym, że nie mówimy „zajmie mi to x godzin”, tylko „zajmie mi to x razy mniej/więcej niż ta inna rzecz, którą już robiłem/robiłam”.

Nasz umysł posiada bardzo dobrze wykształcony mechanizm porównywania. Jest w stanie ocenić, jak dużo czasu i wysiłku jaka jest proporcja czasu i wysiłku jednego przedsięwzięcia do innego. to z kolei znaczy że potrzebujemy mieć jakiś punkt odniesienia i potem już powinno pójść łatwiej. Oczywiście, w rezultacie nie dostajemy wcale oszacowania w godzinach, ale proporcje pomiędzy poszczególnymi wymaganiami.

Skala Story Points, a ciąg Fibonacciego

W przypadku Story Points każde kolejne oszacowane wymaganie daje nam więcej punktów odniesienia. Jeżeli wiemy, że czas i wysiłek w przypadku jednego wymagania określiliśmy na „pięć punktów” to bez problemu rzecz o podobnym skomplikowaniu i czasochłonności też oceniamy na „pięć punktów”. Coś co jest łatwiejsze, prostsze i szybsze będzie oszacowane na dwa lub trzy punkty, a coś trudniejszego na przykład na osiem.

Celowo w ramach tego tekstu nie wspominam o żadnej skali, ani o tym „co konkretnie znaczą te punkty”. W założeniu Story Points są miarą abstrakcyjną. Story Pointy odzwierciedlają tylko i wyłącznie proporcje pomiędzy poszczególnymi wymaganiami. Jeżeli jakaś praca jest wyszacowana na jeden punkt, a drugie na dwa, to możemy śmiało powiedzieć, że to drugie jest dwa razy „większe” niż to pierwsze.

No dobrze, ale co to nam daje? Jak właściwie mamy używać Story Pointów do planowania? Tu potrzebujemy jakichś wartości liczbowych. Najpopularniejszą skalą jest ta oparta o Ciąg Fibonacciego, czyli 1, 2, 3, 5, 8, 13, 21, itd. Każdy element ciągu jest sumą dwóch poprzednich. Ta skala pomaga nam w uchwyceniu proporcji pomiędzy rzeczami małymi i dużymi. Nie zastanawiamy bowiem, czy coś jest warte „osiem” czy „dziewięc”, bo jeśli tylko już stwierdziliśmy, że jest większe niż 8 punktów, to kolejnym elementem w ciągu jest 13. Za każdym razem pytamy „Czy to jest większe niż?”

„Czy to jest większe niż 8? Tak. „Czy to jest większe niż 13? Nie. Oszacowanie wynosi 13.”

To pozwala nam na uchwycenie dużych różnic, ale też na niejako „za darmo” uwzględnia złożoność i fakt, że w dużych wymaganiach bardzo często ukrywają się rzeczy, o których nie mamy pojęcia. Stosoując Story Points nie próbujemy oszacować wielkości dokładnie tylko chcemy uzyskać wystarczająco dobre przybliżenie, które pozwoli nam na skuteczne i efektywne szacowanie.

Mając wymagania oszacowane w ten sposób bardzo łatwo jest się zaplanować. Ponieważ wiemy, ile mniej więcej wymagań zrealizowaliśmy w poprzednich Sprintach, to jesteśmy w stanie planować podobną liczbę punktów. Oczywiście, takie szacowanie to nie jest apteka. Przez to, że Ciąg Fibonacciego ma dziury, to oszacowanie nigdy nie są precyzyjne. Tylko dzięki temu mamy też większą szansę na osiągnięcie sukcesu, bo jak pokazuje doświadczenie nas wszystkich, raczej mamy tendencję do niedoszacowania niż przeszacowywania.

Alternatywy dla szacowania w Story Points

Chyba najbardziej popularną alternatywą do Story Pointów, są dni i godziny czyli stare dobre manday’e. Problem z manday’ami jest taki, że szacujemy wtedy poszczególne zadania poszczególnych osób, a nie wymagania jako całość. Próbujemy w ten sposób złapać nieuchwytne czyli określić co konkretnie jest do realizacji, zamiast skupić się na ogólnym uchwyceniu możliwości zespołu w kontekście tego konkretnego wymagania. Inaczej mówiąc: skupiamy się na sposobie realizacji, a nie na samym wymaganiu.

Miary oparty o czas niestety przybliżają nas do podejścia projektowego, gdzie musimy się rozliczać z czasu i dbać o to, żeby właściwie go potem zaraportować. To nie ma nic wspólnego z podejściem zwinnym, a już w ogóle – ze Scrumem.

A gdyby tak nie szacować?

Druga alternatywa popularna alternatywa do szacowania w Story Pointach, to nie szacowanie w ogóle. Ruch o nazwie #NoEstimates sugeruje, że jeżeli wszystkie wymagania są podobnego rozmiaru, to tak naprawdę nie musimy szacować w ogóle! Wystarczy przecież, że skupimy się na liczbie wymagań, a nie ich wielkości.

Ma to sens. Jeżeli średnio nasze Elementy Backlogu Produktu mają wymiar trzech Story Pointów, a realizujemy ich 10 w każdym Sprincie, to z punktu widzenia zespołu nie ma żadnej różnicy czy będzie on planował sobie „mniej więcej 10 wymagań” czy „mniej więcej 30 Story Points”.

Pamiętajmy, że nie szacujemy w celach zarządczych ani raportowych. Szacujemy po to, żeby potrafić się lepiej zaplanować. To z kolei znaczy, że zgrubne szacowanie ilością liczbą wymagań będzie równie skuteczne. Jedyną trudnością jest doświadczenie wymagane do dzielenia wszystkich wymagań na elementy podobnej wielkości. Większość zespołów musi przejść przez etap szacowania po to, żeby koniec końców dotrzeć do punktu, w którym potrafią sprawnie dzielić wymagania i nie muszą ich szacować.

Techniki szacowania i inne pomysły

Sama koncepcja Story Points nie jest skomplikowana. Bardzo łatwo jest jej używać, kiedy dobrze zrozumiemy istotę „SP” i samych wymagań biznesowych. Niestety, dla wielu osób przyzwyczajonych do precyzyjnych miar, koncepcja zgrubnego szacowania i to jeszcze przy użyciu liczb, jest dziwna.

Do tego dochodzi problem z faktycznym zastosowaniem Story Pointów w praktyce. Jedna rzecz to techniki, gdzie chyba najpopularniejszy jest Planning Poker, który równie często jest niezrozumiały i stosowany źle. Ale zupełnie osobną kwestią są nieporozumienia w kontekście szacowania w ogóle – po co to robimy i „ile manday’ów to jeden Story Point”. W szczególności jeśli ma ich używać Product Owner czy Project Manager do zarządzania backlogiem czy projektem.

To jednak temat na zupełnie inną inny tekst, a nawet na książkę. W tym miejscu serdecznie polecam naszą książkę „Szacowanie: Story Points i nie tylko„, gdzie tą koncepcję opisujemy w szczegółach. Dajemy tam też wiele różnych porad i omawiamy wszystkie znane nam techniki szacowania. A gdyby tego było Wam mało, szacowanie ćwiczymy też na naszych szkoleniach i warsztatach.