Dlaczego warto używać Story Points?

7 stycznia 2019 Michał Gorski

Story Points (SP) usprawniają proces estymowania projektu programistycznego. To metoda wspierająca rozwijanie oprogramowania wykorzystywana głównie przez project/product managerów. Story Points są pomocne wszędzie tam, gdzie należy oszacować wielkość backlogu, wyznaczyć budżet, harmonogram, raportować postęp prac, szacować wielkość zmian. Dla Product Ownerów SP będą metodą ułatwiającą podejmowanie decyzji w oparciu o zwrot z inwestycji, czyli ROI (Return On Investment).

Michał Gorski. Head of Delivery, DO OK S.A. Manager IT z dwunastoletnim doświadczeniem w IT, z czego pierwsze cztery jako programista i architekt oprogramowania. W pracy wykorzystuje zwinne metodyki zarządzania projektami, aby maksymalizować wartość biznesową dostarczanych produktów.

Spis treści

Co to w ogóle jest Story Point?

Story Point jest relatywną miarą elementu do realizacji w Product Backlogu. Product Backlog jest listą ułożoną według priorytetów (głównie funkcjonalności oprogramowania) do realizacji w projekcie, są to tak zwane PBIs — Product Backlog Items.

Przeważnie pojedynczy PBI sprowadza się do implementacji jakieś historyjki (ang. *story*) użytkownika opowiadanej o funkcjonalności – stąd też nazwa *Story* Points.

Ilość punktów przypisywana PBI powinna pokrywać niezbędną ilość prac do wykonania, złożoność implementacyjną oraz ryzyko, które wiąże się z implementacją.

Historycznie SP zawierały tylko wymiar złożoności. Jednakże pracując tą metodą przez ponad 10 lat, z czasem zauważyłem, że dodanie dwóch dodatkowych wymiarów pomaga mi w osiąganiu lepszych rezultatów.

Zobacz też

growth hacks Od kolorowych karteczek po implementację kodu. Autostopem przez Domain Driven Design

Estymacja oraz harmonogramowanie bez użycia Story Pointów

Aby przygotować projekt do realizacji, kierownik projektu musi odpowiedzieć na trzy podstawowe pytania: co jest do realizacji (zakres), kiedy będzie to wykonane (harmonogram), ile to będzie kosztowało (budżet).

Głównym składnikiem wyznaczającym budżet w projektach IT są koszty rozwoju oprogramowania przy tworzeniu funkcjonalności. Estymacja jest realizowana przy pomocy roboczogodzin (man hours) lub roboczodni (man days).

Po wyznaczeniu budżetu następuje harmonogramowanie. Można to zrealizować na wiele sposobów, ale w uproszczeniu polega to na rozdzieleniu zadań w zespole oraz uwzględnieniu zależności, dostępności zespołu oraz szeregu innych czynników.

Na końcu kierownik projektu dostarcza początkowy budżet oraz harmonogram do realizacji zakresu. Daty oraz budżet są zapamiętane, a sukces projektu jest zbyt często mierzony czy udało się utrzymać projekt w wyznaczonych ramach.

Niestety, programiści i kierownicy projektów nie są w stanie w pełni przewidzieć przyszłości. Zdarza się, że zwyczajnie mogą się mylić. Wiele ryzyk może się zmaterializować. Otoczenie projektu może nie być optymalne do zakładanej prędkości realizacji (opóźnienia w procesie decyzyjnym, standardy kodu wcześniej nie komunikowane, długi proces wdrażania czy integracji kodu źródłowego).

Założenia poczynione podczas estymacji mogą okazać się nieprawdziwe (np. biblioteki/ narzędzia, które miały uprościć implementację nie sprawdzają się). Środowisko projektu może się zmienić, a co za tym idzie niektóre produkty projektu również należy dostosować.

Kiedy powyższe elementy mają miejsce, bardzo ciężko jest oszacować ich wpływ na budżet i estymacje. Ciągłe zmiany budżetu względem zadań wykonywane wraz z zespołem nie zawsze jest praktyczne. Takie podejście odciąga uwagę zespołu programistycznego od tego, co jest najistotniejsze – sukces projektu oraz tworzenie oprogramowania.

Estymacja zadań pozwala planować, ale nie zmieni kiedy realnie zadanie zostanie ukończone (ew. nadmierna estymacja może wpłynąć na zamknięcie całego projektu lub przeplanowanie względem ROI). Ponadto warto wspomnieć o wyzwaniach związanych z dyskusjami dotyczącymi wpływu poszczególnych wydarzeń czy okoliczności na całość projektu.

Inna droga

Z praktycznego punktu widzenia posiadanie przybliżonego kosztu projektu jest bardziej istotne niż estymacje na poszczególnych zadaniach. Lepsze rezultaty przynosi skupianie się na dostarczaniu wartości oraz monitorowanie jak początkowe przybliżenie ma się do realizacji.

Praca ze SP zaczyna się od przygotowania backlogu (zakresu). Następnie każdemu elementowi backlogu (PBI) przypisywana jest relatywna wartość w SP. Początkowo przypisuje się 2 SP elementowi, który jest dobrze zrozumiany, nieskomplikowany oraz nie są z nim związane ryzyka. Jeśli element jest trywialny ma przypisany 1 SP.

Następnym krokiem jest relatywna estymacja wszystkich pozostałych elementów backlogu w relacji do już wyestymowanych względem innych. Jeśli zespół ma znaczące problemy przy estymacji jakiegoś elementu, to należy ów element pominąć oraz wrócić do niego później.

Standardem w branży jest stosowanie przybliżonego ciągu Fibonacciego (1, 2, 3, 5, 8, 13, 20, 40…). Dlatego jeśli element jest około 50% większy od pierwszego (2 SP) to przypisywane są mu 3 SP. Ta sama logika stosowana jest przy większych wartościach.

Jeśli pojawia się ryzyko dotyczące elementu (np. jest nieznany pewien obszar, który może spowodować dodatkową pracę) zespół stara się oszacować wpływ tego ryzyka na wartość w SP. W większości przypadków zwiększa to wartość o jeden stopień – np. z 5 SP do 8 SP.

Jeśli do wykonania jest znacząco skomplikowany element (np. algorytm) powinno to również zwiększyć estymacje w podobny sposób, kierując się głównie wyczuciem zespołu jak bardzo (np. z 2 SP do 3 SP czy z 5 SP do 13 SP).

Zobacz też

PM Strategia, budowa i rozwój produktu IT okiem Product Managera

Po wyestymowaniu całego backlogu w ten sposób należy przybliżyć pracochłonność około 15-20% backlogu w roboczogodzinach. Pozwoli to na przybliżenie prędkości zespołu realizacji elementów backlogu (upraszczając: średnia ilość SP w perspektywie czasu – np. 20 SP w przeciągu 2 tygodni).

Przykładowe założenie projektu: 25% backlogu to 420 roboczogodzin (włączając w to naprawianie błędów, przegląd kodu, i inne w zależności od środowiska), a cały backlog to 300 SP, zespół spędza około 15% na planowaniu prac, przeglądzie procesu oraz przeglądzie postępów prac, dostępność 5-osobowego zespołu w przeciągu dwóch tygodni to około 320 godzin (w uproszczeniu z chorobowym, urlopami, dniami wolnymi od pracy oraz innymi organizacyjnymi), czyli wyjściowa optymistyczna prędkość zespołu w przeciągu dwóch tygodni wynosiłaby około 48,5 SP. Projekt w optymistycznym wariancie zajmie co najmniej 7 sprintów. Raczej nie będzie to 6,2 sprintu (300 sp / 48,5 sp) – w większości przypadków zostanie coś dodane lub jakieś ryzyko negatywnie wpłynie na harmonogram.

Cały backlog: 300 SP

25% backlogu: 75 SP

420 h pracowania nad oprogramowaniem to 75 sp => 5.6 h / SP (aby zaimplementować 1 SP zespół będzie pracował około 5.6 h)

1 sprint (dwa tygodnie) to 320 h; to jest 5 osób może przepracować 320 h w dwa tygodnie (5 osób * 5 dni w tygodni * 2 tygodnie * 8 godzin w trakcie dnia minus 20% na inne)

15% zajmuje planowanie prac i inne.

Możliwości pracowania nad pisaniem oprogramowania na sprint to 320*85% => 272 h

W 272 h zespół jest w stanie zrealizować 48,5 SP (272 h / ( 5.6 h / SP)).

Ponadto musi mieć miejsce typowe harmonogramowanie oraz planowanie. Jest to niezbędne, aby zaadresować zależności pomiędzy grupami zadań, założenia oraz inne mające wpływ na realizację.

Praca z zakresem oraz reagowanie na zmiany

Po zrealizowaniu co najmniej dwóch sprintów project manager musi weryfikować początkowo estymowaną prędkość względem realizacji. Służy to bieżącej weryfikacji kondycji projektu względem początkowych założeń oraz planu na przyszłość.

Jeśli występuje różnica pomiędzy projekcją a realizacją w prędkości, to powody oraz przyczyny powinny być zrozumiane a harmonogram, budżet oraz inne elementy realizacji projektu powinny być odpowiednio odzwierciedlone w zaktualizowanym planie.

Po pewnym czasie prędkość zespołu ustabilizuje się, a środowisko oraz wpływ części ryzyk będzie w niej odzwierciedlony. Plan projektu będzie też uwzględniał dotychczasowe doświadczenia zespołu oraz ich realne umiejętności w konkretnym projekcie.

Możliwe jest oszacowanie zmian otoczenia projektu (jeśli takie zaistnieją) względem prędkości prac zespołu. Samą prędkość prac również można względnie dostosować. Pojawienie się nowych funkcjonalności również jest szacowane w SP. Ułatwia to zrozumienie ich wielkości oraz ich zwrot z inwestycji (ROI), w konsekwencji czy rzeczywiście są warte inwestowania oraz zmiany planów.

Kiedy estymacje odbywają się w SP, wszyscy rozumieją, że estymacja tylko przybliża niezbędną pracochłonność w realizacji. Nie jest ona absolutna i może się zmieniać w zależności od ryzyk, obostrzeń (ang. constraints), itd.

Niestety, estymacje w roboczogodzinach czy dniach roboczych zbyt często są traktowane jako zdefiniowane, niezmienne i bezbłędne, jeśli chodzi o planowanie oraz realizację projektów o wysokim ryzyku takich jak projekty IT. Brak zrozumienia wysokiego ryzyka i zmienności projektu rodzi nieporozumienia pomiędzy zespołem projektowym a właścicielami produktów.

Korzyści ze stosowania SP

realistyczny planning na podstawie prędkości zespołu odzwierciedlający ryzyka oraz wpływ środowiska na realizację,
zespół pracujący nad jednym backlogiem mierzy postęp prac według jednej miary,
zespół wspiera się, by zmaksymalizować wspólny wysiłek.

Co pozostaje niezmienne?

komunikacja pomiędzy wszystkimi zaangażowanymi w projekt nadal pozostaje kluczowa w dostarczaniu tego co naprawdę jest niezbędne. Dotyczy to także zarządzaniem oczekiwaniami oraz interesariuszami,
nie ma potrzeby angażowania Scrum Mastera; promowaniem odpowiednich postaw i metod mogą (nadal) zajmować się liderzy (formalni i nieformalni: kierownicy liniowi, kierownicy projektów, programiści),
nadal należy zarządzać ryzykiem, założeniami, wyzwaniami, zmianami i zależnościami,
model współpracy musi być dostosowany do warunków: fixed price lub time & material.

Praktyczne rady

upewnij się, że SP są addytywne: zespół powinien być w stanie dostarczyć 8 SP w podobnym czasie jak dwa elementy o wartościach 5 SP i 3 SP,
oszacuj backlog z tym samym zespołem, który będzie realizował projekt,
1 SP powinien zająć od 1 do 3 dni pracy jednego programisty. W większości przypadków jest to bliżej 8 godzin pracy. Pomaga to stworzyć backlog o odpowiedniej granularności,
zespół powinien być w stanie zrealizować największy element w przeciągu jednego sprintu (np. dwóch tygodni),
jeśli pojawiają się większe elementy niż 40 SP, należy zdekomponować je na mniejsze nawet na początku projektu. Zbyt wysokie estymacje mogą prowadzić do mniej przewidywanego projektu ze względu na niezidentyfikowane ryzyka czy zakres,
upewnij się, że zespół rozumie sposób estymacji oraz jak prędkość zespołu jest przybliżana. Pozwoli im to pracować z liderami projektu, aby przybliżyć realizację do początkowego planu (głównie harmonogramu),
sprawdź czy intuicja zespołu jest zgodna z przewidywaną prędkością. Jeśli predykcja jest około 30 SP / 2 tygodnie to sprawdź czy czują, że w 6 tygodni są w stanie zrealizować zakres “warty” 90 SP. Jeśli te wartości nie są spójne, warto zainwestować dodatkowy czas w poznanie przyczyn takiego stanu,
po estymacji przyjrzyj się z zespołem grupom elementów o tych samych wartościach (np. czy wszystkie “trójki” są do siebie “podobne”) i sprawdź, czy są one porównywalne w trzech płaszczyznach: pracochłonność, złożoność, ryzyka. Pozwala uniknąć to nieporozumień i błędów w estymacji na wczesnym etapie.

Kiedy nie należy stosować Story Points?

- zespół jest i będzie zmienny i ciężko byłoby się posługiwać prędkością zespołu,
- zespół jest bardzo mały (1-2 programistów),
- nie ma potrzeby dostarczenia harmonogramu (np. prace w R&D),
- projekt jest krótszy niż 2 miesiące,
- w zespole brakuje osób znających metodę SP oraz wszyscy są przyzwyczajeni do pracy z roboczogodzinami, a także dobrana jest odpowiednia struktura project managementu,

członkowie zespołu pracują osobno i nie są w stanie sobie pomagać – np. iOS, Android oraz interfejs przeglądarkowy są rozsynchronizowane oraz mają inne funkcjonalności do realizacji.