Scrum Guide | 23. Estymacja i Story Points w Scrum

Tworzenie estymacji w Scrum służy do szacowania stopnia skomplikowania i czasu potrzebnego do wykonania zadań. Oszacowania dokonuje wspólnie Scrum Team na podstawie swojego dotychczasowego doświadczenia. Dlatego też im bardziej doświadczony Scrum Team, tym trafniejsze są jego estymacje. Scrum Team uzgadnia planowany czas wykonania zadań podczas Sprint Planningu pamiętając jednak, że nie jest on traktowany jako zobowiązanie, lecz prognoza, której trafność mogą zaburzyć niespodziewane trudności w realizacji zadań.

Estymacja i Story Points w Scrum – omówione zagadnienia:

1. Wprowadzenie
2. Znaczenie Story Points w Scrum
3. Relatywne techniki estymacji
4. Podsumowanie

Wprowadzenie

Na każdym Sprint Planningu, Product Owner przedstawia zespołowi nowe User Stories. Product Owner wybiera je z Backlogu Produktu do realizacji w najbliższym Sprincie. Zaś członkowie Scrum Team wspólnie oceniają ilość pracy potrzebną do wykonania tej nowej porcji zadań. Zadanie to nazywane jest estymacją, wyceną wymagań, bądź szacowaniem.

Wydawać by się mogło, że najprostszym sposobem estymacji jest określenie czasu potrzebnego do wykonania zadania w godzinach lub dniach. Jednak praktyka i badania prowadzone już od lat ’40 XX wieku dowodzą czegoś innego. Ludzie nie są w stanie trafnie szacować czasu potrzebnego na realizację nawet bardzo dobrze zdefiniowanych zadań. Poza tym ilość godzin potrzebnych do realizacji zadania jest zależna od tego, kto to zadanie wykonuje, oraz co zostało – lub nie zostało – zrobione wcześniej. Dlatego też w Scrum stosuje się zazwyczaj jednostki zwane Story Points.

Znaczenie Story Points w Scrum

Każdy Zespół Developerski wypracowuje w praktyce wartość jednostki Story Point bazując na swoich wcześniejszych doświadczeniach oraz porównaniu wielkości poszczególnych zadań, czyli kierując się zasadą empiryzmu. Najczęściej podczas Sprint Planningu Scrum Master wybiera jedno lub kilka przykładowych już zrealizowanych User Stories, które stanowią punkt odniesienia dla określenia wartości User Stories wybranych do realizacji.

Zadaniom nie można więc przypisać wartości w Story Points niezależnie od ich kontekstu. Przykładowo, jeśli pierwszemu zadaniu przypisana zostanie wartość 10, kolejne zostanie oszacowane w odniesieniu do niego jako większe bądź mniejsze. W ten sposób w ramach jednego projektu realizowanego przez Scrum Team, wszystkie zadania w Product Backlogu są odnoszone do siebie nawzajem. Oznacza to, że podobne zadania realizowane przez jeden Zespół Developerski otrzymają podobną liczbę punktów.

Story Points są jednostkami relatywnymi.Oznacza to, że:

1. Wartość Story Point odnosi się wyłącznie do zadań wykonywanych przez konkretny Scrum Team. Story Points opisują prędkość realizacji zadań jednego zespołu. Innymi słowy, User Story oszacowana na 10 Story Points przez zespół A może zostać oszacowana na 50 Story Points przez zespół B. Dzieje się tak, ponieważ, jak wspomnieliśmy ich wartość estymowana jest na podstawie i w odniesieniu do innych zadań wykonywanych przez ten zespół, a także jego doświadczenia z podobnymi zadaniami.
2. Wartość Story Points zrealizowanych w jednym Sprincie nie może być podstawą porównania wydajności dwóch Scrum Teams. Aby uniknąć błędów przy zarządzaniu projektami realizowanymi w Scrum należy pamiętać, że Prędkość Zespołu Developerskiego wyrażona w Story Points zrealizowanych w jednym Sprincie nie może służyć do porównywania wydajności dwóch Zespołów. Mogły one bowiem wykonać w równoległych Sprintach identyczną pracę, którą jeden z Zespołów oszacował na 10, a drugi 50 Story Points.

Nie należy również zapominać, że estymacja zawiera wiele elementów niewiadomych i dokonywana jest na bazie niekompletnych danych. Z tego powodu przewidywania nawet bardzo doświadczonego Scrum Team mogą czasem mocno odbiegać od realnego nakładu pracy potrzebnego do realizacji User Story.

Relatywne techniki estymacji

Jakie są zatem najskuteczniejsze techniki estymacji stosowane w Scrum? Nie ma jednej uniwersalnej metody, która sprawdzi się w każdym Scrum Team.

Wśród technik estymacji używanych w metodykach zwinnych stosowane są najczęściej:

1. Planning Poker.Ta najpopularniejsza metoda relatywna polega na użyciu gry w karty do oszacowania ilości pracy potrzebnej do wykonania zadania. Jej szczegółowe zasady i przebieg opisujemy w osobnym artykule.
2. Team Estimation Game.Ten ciekawy i bardzo efektywny sposób estymacji również opisujemy w osobnym tekście. Polega on na przypisaniu User Stories przeznaczonych do realizacji w danym Sprincie odpowiednich wartości liczbowych wybranych z ciągu Fibonacciego.

Natomiast z reguły nie stosuje się w Scrum estymowania klasycznego (Absolute Estimation) używanego w tradycyjnym zarządzaniu projektami. Klasyczny sposób szacowania zadań polega bowiem na określeniu z góry osobomiesięcy, czasu trwania i kosztu całego projektu. Jest to proces długotrwały, trudny w realizacji, oraz wymagający udziału ekspertów, którzy niekoniecznie będą wykonywać zadania, których wartość oszacowali. Innymi słowy, jest on nie tylko żmudny, ale również wysoce nieefektywny.

Podsumowanie

Estymacja jest bardzo ważną umiejętnością, którą musi posiąść dojrzały Scrum Team. Umiejętność szacowania ilości czasu i wysiłku potrzebnych do realizacji zadań jest trudną sztuką. Dlatego by uczynić ją bardziej efektywną, opracowano relatywne techniki estymacji: Planning Poker i Team Estimation Game. Wycenianie User Stories przy użyciu Story Points jest szybszą i skuteczniejszą metodą niż używanie innych miar estymacji. Należy jednak pamiętać, że ich wartość odnosi się jedynie do zadań wykonywanych przez konkretny Scrum Team. Ilość Story Points nie może być więc podstawą porównywania Prędkości różnych Zespołów Developerskich.

Zapoznaj się z kolejnym wpisem z ej serii: Jak działa Planning Poker?

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.