Blog

Wiele zespołów pracujących zwinnie posługuje się bezwymiarowymi Story Pointami do szacowania wymagań, zamiast określać czas niezbędny do ich realizacji w godzinach lub dniach. To dobra, choć czasami problematyczna praktyka, mająca niewątpliwie tę zaletę, że nie prowokuje do prostego sumowania godzin czy dni, aby określić „na kiedy ten feature będzie gotowy”.

Szacowanie przy pomocy Story Pointów sprowadza się do tego, że porównujemy wymagania ze sobą i w oparciu o te porównania przypisujemy im wartości liczbowe określające ilość pracy niezbędnej do wykonania. Jeśli szacowane wymaganie jest ciut bardziej pracochłonne niż to wyszacowane wcześniej na 8 punktów, damy mu estymatę wyższą niż 8. Jeśli pracochłonność jest dużo mniejsza, estymata będzie niższa niż 8. Jeśli zaś to wymaganie wymaga tylko odrobinę mniej pracy od tego z szacunkiem 8 pointów, zapewne przypiszemy mu tych punktów również 8.

Planning Poker

Najbardziej rozpowszechnioną skalą szacowania w Story Pointach jest ciąg liczb stosowany w technice Planning Poker: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 oraz 100. Szacunek „0” może oznaczać, że wymaganie zostało już zrealizowane, lub że tej pracy jest znikoma ilość i da się ją zrobić „z marszu”, na przykład w kwadrans. „100” wskazuje, że wymaganie jest ogromne i najpewniej będzie wymagało dekompozycji na kilka mniejszych przed rozpoczęciem realizacji w iteracjach.

Patrząc na listę możliwych estymat dostrzegamy, że nie są to kolejne liczby, ani też nie jest tak, że każda z nich jest proporcjonalnie większa od poprzedniej. Posługujący się Planning Pokerem często bawią się w arytmetykę typu „skoro to wymaganie jest dwa razy większe od tego za 3 punkty, to dajmy mu 6 punktów”; efektem jest uzupełnienie skali ocen o wszystkie możliwe wartości pośrednie.

Tymczasem szacunek „5” w tej skali oznacza „większy niż 3, a zatem 4 lub 5”. Szacunek „8” oznacza „większy niż 5, a więc 6, 7 lub 8”. I tak dalej. We wspomnianym wcześniej przykładzie, jeśli wydaje nam się, że wymaganie jest dwa razy „większe” od tego wyszacowanego wcześniej na 3 punkty, to powinniśmy mu przypisać estymatę 8.

Rosnąca niedokładność oszacowań

Logiczną konsekwencją opisanego wcześniej mechanizmu szacowania jest spadająca precyzja estymat wraz z ich wzrostem. Bo przecież estymata 8 może oznaczać, że wymaganie jest ciut większe od tego z szacunkiem 5, a może 8 jest faktycznie „w sam raz”. Jeszcze lepiej to widać na szacunku 100: oznacza, że wymaganie, któremu przypisujemy tę liczbę jest albo takie, jak inne wymagania 40-to punktowe, albo może i dwa i pół razy większe od nich.

Oznacza to, że na przykład dla estymaty 40 punktów błąd szacowania wynosi 50%, dla 100 punktów aż 75%. Innymi słowy, jeśli przypisujemy wymaganiu 40 punktów jedyne co wiemy, to że wymaganie jest większe od tego za 20 punktów, ale dokładna wartość mogłaby mieścić się w przedziale od 20 do 60 punktów (bo obszar niepewności, czy tego chcemy czy nie, rozciąga się przecież w obie strony od wskazanej wartości). A nie można zapomnieć, że i 20-to punktowe wymaganie, w stosunku do którego relatywnie estymujemy ma szacunek 20 obłożony stosownym dla tej estymaty błędem (i realnie jest to przedział od 13 do 27 punktów)…

Dekomponujmy wymagania!

Posługując się Planning Pokerem zespół powinien dążyć do umiejętności szacowania w miarę możliwości w dolnej części związanej z metodą skali. Jest to ważne zwłaszcza dla wymagań uznawanych za realizowalne w czasie jednej iteracji. Wydaje się, że granicą rozsądną jest tutaj 13 punktów, a zatem estymaty 20, 40 lub 100 powinny oznaczać potrzebę dekompozycji zbyt opasłego, skomplikowanego lub niejasnego elementu backlogu.

Jeśli zespół posługuje się głównie oszacowaniami klasy 20 i 40 punktów dla wymagań realizowanych w iteracji, a jego velocity liczone jest w dziesiątkach (czasami setkach punktów), warto zastanowić się na retrospektywie nad tym, czy podzielenie tych szacunków przez dziesięć nie miałoby sensu. W ten sposób skala ocen zostanie urealniona.

Natomiast jeśli zespół posługuje się oszacowaniami zarówno z góry jak i dołu skali (czyli w backlogu ma elementy tak z szacunkiem 1 i 2 punkty, jak i te z 20 i 40 punktami), po czym realizuje te „duże” bez dekompozycji na mniejsze elementy, dyskusja o sposobie szacowania staje się krytyczna. Dlaczego? Bo tak duży rozrzut estymat dla wymagań, które da się zrealizować w porównywalnym czasie, jest mało prawdopodobny, o ile te oszacowania robione są choćby trochę na serio.

Gdy punkty sprawiają problemy

Czasami lepiej odejść od ciągów liczb z metody Planning Poker i użyć wartości oszacowań, które są jeszcze mniej podatne na próby sumowania, dzielenia i mnożenia ich przez siebie. XXS, XS, S, M, L, XL i XXL – to jeden z możliwych sposobów. Rzecz jasna na potrzeby wyliczania velocity trzeba przypisać im jakieś wartości liczbowe.

Zdarzają się też zespoły, które posługują się tylko trzema estymatami: „nie potrafimy oszacować”, „za duże”, „zmieści się w iteracji”. Wtedy można pokusić się o podejście #noestimates, choć trzeba cały czas pamiętać, że brak przypisania wartości liczbowej czy tekstowej jako estymaty nie oznacza, że szacowanie się nie odbywa. Aby dojść do poziomu „zmieści się w iteracji” trzeba wcześniej dokonać dekompozycji i… oszacowania wymagań, które w wyniku tego procesu powstają. W tym przypadku owo szacowanie sprowadza się do oceny, czy elementy backlogu są już dostatecznie małe czy nie.

A wy jak szacujecie wymagania w waszych backlogach?