Szacowanie w Scrum – Story Points i alternatywy 

Story Points, czyli „szacowanie w punktach” to temat od którego nie da się uciec, gdy rozmawiamy o backlogu. Story Points, podobnie jak User Story nie są elementem Scruma. Ale i jedna, i druga technika występują zaskakująco często razem z naszą ulubioną metodyką.

Estymacja, czyli szacowanie

Z jednej strony istnieje wiele sprawdzonych metod szacowania, a z drugiej popularność zyskuje ruch o nazwie #NoEstimates, który promuje zaniechanie wyceny elementów backlogu. Wszystko co wiemy o szacowaniu – zarówno pod względem teorii, jak i praktyki oraz technik – zawarliśmy w naszej książce „Szacowanie: Story Points i nie tylko„. Polecamy ją serdecznie, a w tym tekście zastanowimy się po co to wszystko i kto właściwie ma rację w temacie szacowania? Zgodnie ze źródłem metodyki:

„Elementy Backlogu Produktu posiadają następujące atrybuty: opis, kolejność, oszacowanie i wartość.” – Scrum Guide

Szacowanie wymagań jest więc czynnością niezbędną, przynajmniej jeżeli chcemy pracować w Scrumie, a nie w ScrumBut. Wiemy już, że trzeba, kolejnym pytaniem będzie więc po co to właściwie robimy?

Wycena, którą nadajemy elementom Product Backlogu pomaga nam zaplanować prace w poszczególnych iteracjach. Znając szybkość zespołu per Sprint (ang. velocity) i wyceny poszczególnych wymagań (zapisanych np. w postaci User Story) jesteśmy w stanie prognozować, które elementy Product Backlogu będą zrealizowane w kolejnym Spricie.

Co więcej, jesteśmy też w stanie odpowiedzieć na pytanie, kiedy mniej więcej zostanie zrealizowane konkretne wymaganie, przy założeniu, że nie dojdzie do zmiany kolejności poszczególnych elementów Product Backlogu. Taką wiedzę obowiązkowo powinien posiadać Product Owner, ale zwykle jest ona powszechna.

Szacowanie względne bez Story Points

Dokonując wyceny elementów backlogu zespół powinien wziąć pod uwagę następujące czynniki: ryzyka, niepewność, złożoność oraz nakład pracy. Wydaje się, że wszystkie one wpływają na wycenę w jednakowy sposób. Tym bardziej, że są one od siebie zależne.

Im bardziej złożone wymaganie, tym większy nakład pracy oraz większe ryzyko i niepewność związane z jego realizacją. Z drugiej strony, realizacja wymagania mało skomplikowanego (np. wykonywanego cyklicznie) będzie wiązało się z mniejszym ryzykiem i niepewnością, mniejszą złożonością i prawdopodobnie mniejszym nakładem pracy.

Pojęcia, których użyłem powyżej (większe/mniejsze) są pojęciami względnymi. Nie można bezwzględnie określić jaka wartość wyceny uznawana będzie za większą, a jaka za mniejszą. Wycena tego samego wymagania w dwóch zespołach może dać różne wyniki. I słusznie, bo takie rzeczy jak ryzyko, niepewność i nakład pracy zależą między innymi od doświadczenia poszczególnych osób.

Story Points są najpopularniejszym sposobem szacowania względnego w agile’owych przedsięwzięciach. To nie znaczy, że są jedynym. Ale to znaczy, że z jakiegoś powodu to właśnie ten sposób jest najwygodniejszy…

Kiedy szacować elementy backlogu?

Product Backlog może podlegać estymacji w każdym momencie, nawet zaraz po wpisaniu ich na listę wymagań. Im wyżej dany element Backlogu Produktu znajduje się na liście, tym jego wycena powinna być dokładniejsza. To znaczy, że wymagania na szczycie listy powinny być oszacowane tak dokładnie, żebyśmy wiedzieli czy zmieszczą się do realizacji w następnym Sprincie.

Analogicznie, estymata elementów znajdujących się nisko na liście wymagań, czyli planowanych do realizacji w późniejszym terminie, może być zgrubna. Na moment szacowania nie ma znaczenia, czy wycenimy wymaganie na 3 czy na 5 Story Points. Zanim dojdzie do jego realizacji może stać się ono zbędne albo możemy zaimplementować funkcjonalność znacząco upraszczającą jego wykonanie. Może też, jak to często bywa, zmienić się jego zakresu, co w sposób istotny wpłynie na szacunek.

Dokładnej estymaty powinniśmy więc dokonywać w momencie, kiedy wiemy już, że element Product Backlogu będzie realizowany (np. podczas Product Backlog Refinement tuż przed rozpoczęciem Sprintu). W części źródeł znajdziecie wskazówkę, aby dokonywać ostatecznej wyceny podczas planowania sprintu, jednak szacowanie wymagań nie powinno być celem spotkania o nazwie Sprint Planning.

Dlaczego estymujemy w Story Points?

Wymagania znajdujące się w Product Backlogu mogą być oszacowane przy użyciu różnych miar. Najczęściej spotkamy się ze Story Points, godzinami (zamiennie używane wraz z manday’ami) czy wartościami pieniężnymi.

Wycena przy użyciu miar bezwzględnych (czas, pieniądze) spowoduje, że finalne oszacowanie i tak zostanie zaokrąglone do pełnych dziesiątek, setek lub tysięcy.  Nie będziemy podawać wartości w stylu 13432,32 zł ani nawet 13500 tylko albo 10 albo 15 tysięcy.

Zastanówmy się też, czy jesteśmy w stanie wskazać wartość pieniężną albo godzinową, którą możemy przypisać do ryzyka i niepewności związanego z realizowanym wymaganiem? Czy jesteśmy w stanie powiedzieć, że wyceniamy ryzyko na 10 000 PLN albo 2 dni robocze? A jeśli nawet pokusimy się o wskazanie tej wartości, to czy czujemy że jest ona prawdziwa?

Właśnie z uwagi na powyższe do wyceny elementów Product Backlogu wykorzystywane są Story Points. Są one niczym innym jak względną miarą przypisywaną do wymagań. Może ona obrazować cokolwiek: punkty, żelki, groszki czy króliki. Miara ta ma nam jedynie pozwolić na porównanie wymagania względem innych, znajdujących się na tej samej liście i realizowanych przez ten sam zespół.

Uprzedmiotowienie miary, nadanie jej abstrakcyjnej formy ma pozwolić zespołowi na wycenę wymagania z pominięciem elementów stricte związanych z budżetowaniem projektu. Pozwala to spojrzeć na wymaganie z uwzględnieniem czynników opisanych powyżej. Mówiliśmy też o tym w naszym wystąpieniu na Agile Warsaw.

Ciąg Fibonacciego, a Story Points

Do szacowania przy wykorzystaniu miary względnej, jak np. Story Points, wykorzystywany jest najczęściej ciąg Fibonacciego. Każdy element ciągu jest sumą dwóch poprzedzających. Elementy ciągu prezentują się więc następująco:

(0), 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 …

Im większe wymaganie i im mniej wiemy o koniecznych do implementacji funkcjonalnościach, tym nasza wycena posiada większy margines. Nie ma więc znaczenia, czy wymaganie wycenimy na 15 punktów czy na 17. Przyjmuje się, że w takim przypadku wycena wymagania powinna przyjąć wartość kolejnej liczby w ciągu, czyli 21.

Zastosowanie ciągu Fibonacciego pozwala nam zatem na szacowanie wymagań w sposób względny, nie przypisując im dokładnej wartości, a jedynie przybliżoną opartą o aktualnie posiadaną wiedzę w kontekście wymagania.

Ciąg ten sprawdza się też idealnie do porównywania wymagań. Wiemy, że praca oszacowana na 8 Story Points jest „ponad dwa razy większa” niż ta oszacowana na 3. Instynktownie czujemy różnicę pomiędzy „wymaganiem za 5”, a „wymaganiem za 13”. Możemy też domniemywać, że zamiast jednej „ósemki” zmieścimy w te miejsce „dwie trójki” albo „trzy dwójki”.

Alternatywą jest oczywiście ciąg liniowy, jednak jego wykorzystanie sprowadzi się do próby dokładnego oszacowania wymagania (15 czy 17?). Spowoduje to ponownie sytuację, w której będziemy starali się wskazać konkretną wycenę, która może nie mieć żadnego uzasadnienia w rzeczywistości.

Nakład pracy na szacowanie

Czy obowiązek szacowania Backlogu Productu znajdujący się w Scrum Guide jest zasadny? Czy nakład pracy związany z koniecznością szacowania każdego z elementów listy wymagań zwróci się nam w przyszłości?

Wydaje się, że tak. Szacowanie elementów listy wymagań ułatwia planowanie sprintu, a także identyfikację skomplikowanych, ryzykownych i wymagających dużego nakładu pracy wymagań. Pomaga nam wskazać, które z nich wymagają dalszego doskonalenia lub podziału na mniejsze części. Pozwala nam więc na lepszą pracę z wymaganiami.

Szacowanie zmusza nas do zastanowienia się nad innymi aspektami realizowanej funkcjonalności prócz samego nakładu pracy. Błędem byłoby stwierdzenie, że ryzyko i niepewność czy złożoność są mniej ważnymi aspektami, a ich nie da się wprost wyrazić w manday’ach.

Ile czasu trzeba poświęcić na wycenę 100 wymagań znajdujących się w naszym Backlogu? Istnieje wiele technik szacowania, które pozwalają na oszacowanie wielu wymagań w naprawdę krótkim czasie. Ale to już temat na zupełnie inny artykuł.

Mało? W naszej książce „Szacowanie: Story Points i nie tylko” zawarliśmy wszystkie znane nam techniki szacowania, porady dotyczące tego jak szacować oraz kompletne wprowadzenie w tematykę szacowania względnego i bezwzględnego. Zachęcamy do zakupu!