Estymacja pracy w Scrum, oszacowanie, ile czasu zajmie zaimplementowanie wszystkich pozycji, wszystkich User Stories z Backlogu Produktu (Product Backlog) jest nader kłopotliwe.
Dla wielu zespołów, w szczególności tych, które mają mniejsze doświadczenie w wykorzystaniu z metodyk oraz frameworków zwinnych (np. Agile, Scrum), zadanie to może być nader trudne.
Problematyka estymacji czasu pracy jest złożona, szerzej o tych problemach pisaliśmy w artykule pt. “Jak estymować pracę elementów Backlogu?”.
Zespół developerski, podejmując się estymacji czasu pracy musi być świadom, że trafność, rzetelność szacunków jest zależna nie tylko od wiedzy i doświadczenia, ale także szeregu czynników, w tym także oddziaływania czynników zewnętrznych, których nie zawsze jest świadomy.
Oczywiście, sytuacja nie jest beznadziejna i istnieje szereg technik szacowania czasu pracy koniecznego do implementacji poszczególnych elementów z Backlogu Produktu.
W rekomendowanym powyżej artykule znajdziecie opis kilku z nich.
W niniejszym tekście skupimy się na technice bardzo popularnej, użytecznej i ze względu na jej zalety nader chętnie wykorzystywanej przez zespoły developerskie.
Jeśli nie wiecie, czym są Story Points, Punkty Fabularne - specyficzne dla Agile jednostki miary, to koniecznie zapoznajcie się z niniejszym artykułem.
Czym są Story Points? Dlaczego zyskały taką popularność i są tak chętnie wykorzystywane przez zespoły pracujące w metodykach zwinnych?
Dlaczego warto korzystać z szacowania pracy za pomocą Story Points? Na czym polega estymowanie czasu pracy za pomocą Punktów Fabularnych?
Już za chwilę poznacie odpowiedzi na te pytania i przeczytacie więcej szczegółów o jednej z najpopularniejszych technik szacowania czasu pracy.
Serdecznie zapraszamy do lektury!
Dlaczego szacowanie czasu pracy jest tak problematyczne?
Zacznijmy od kwestii dość oczywistej, ale jednocześnie ważącej na wszystkim. Wpływającej na terminowość, wydajność, ostateczną jakość, konkurencyjność produktu cyfrowego.
Umiejętność dokonywania możliwie najbardziej trafnej, bliskiej prawdy estymacji czasu pracy jest niezbędna, by projekt zakończył się sukcesem.
A więc został wykonany w założonych ramach czasowych, w określonym budżecie, w zgodzie ze złożonymi, nader różnorodnymi oczekiwaniami interesariuszy.
Dokładność każdej estymacji czasu pracy zależna jest od:
- tego, jaką ilością danych dysponuje zespół scrumowy
- na ile te dane są kompletne
- na ile wartościowe, użyteczne, kluczowe są posiadane dane
- stabilności danych - tego, czy są aktualne oraz jak szybko zmieniają się w czasie
- przyjętych punktów odniesienia
- umiejętności dostrzegania analogii, różnic, związków
- doświadczenia w analizowaniu, estymacji, dokonywaniu predykcji
- uwarunkowań zewnętrznych i wewnętrznych, które mają wpływ na przebieg, tempo, bezproblemowość prac
- znajomości kluczowych ryzyk pojawiających się w projektach zwinnych
- znajomości zmienności i regularności procesów
- tego, czy estymacja będzie wykonywana indywidualnie, czy kolektywnie oraz od tego, czy będzie dokonywana przez specjalistów, którzy będą następnie wykonywać daną pracę
- last but not least - przyjętych założeń - kluczowe jest trafne zdefiniowanie zakresu, złożoności, trafności podejmowanych działań.
Ważną zmienną jest także przyjęta miara, jaką będziemy starali się wyrazić pracę. Tradycyjną miarą jest oczywiście czas (z podziałem na miesiące, tygodnie, dni i czasami godziny).
Przy czym, warto mieć świadomość, że czas wyrażony za pomocą danej jednostki, choć może wydawać się obiektywny, bezstronny, łatwo porównywalny, to niekoniecznie jest bezproblemowy, jako narzędzie służące do estymacji.
Czas jako miara w projektach zwinnych nie pozwala:
- uwzględnić pracy wykonywanej poza danym projektem (np. spotkania, rozmowy, korespondencja), która czasowo się pokrywa
- uwzględnić specyfiki pracy danego zespołu
- skoncentrować się na bardziej znaczących i ważkich sukcesach niż termin (np. rozwiązanie problemu technicznego o kardynalnym znaczeniu strategicznym, biznesowym).
Kto choć raz uczestniczył w procesie estymowania czasu pracy elementów Backlogu Produktu ten doskonale wie, że to samo zadanie (np. User Story, Historyjka Użytkownika) przez developerów będzie nader różnie szacowane.
Okazuje się bowiem, że subiektywne poczucie czasu sprawia, że dla każdego specjalisty godzina oznacza trochę coś innego.
Oczywiście, w sensie obiektywnym to wciąż 60 minut i 3600 sekund, ale już w sensie ile pracy, jaką można wykonać w tych 60 minutach i 3600 sekundach jest to, co najmniej problematyczne.
Różne szacunki mają swe źródło w różnych doświadczeniach, kompetencjach, to jasne.
Ale także wynikają z czysto ludzkich kwestii, takich, jak choćby przyzwyczajenia, predyspozycje, motywacje, preferowane wartości, czy mówiąc bardziej ogólnikowo preferowana kultura pracy.
Jeśli zatem niejednoznaczność jest koniecznością, to w jaki sposób można trafnie oszacować i przede wszystkim uzgadniać, ile dane zadanie powinno zająć czasu?
Bezwzględne metody szacowania (np. czasowe) nie zawsze są najbardziej skutecznymi, a całkiem dobrze sprawdzają się metody, techniki relatywne.
Polegają one nie tyle na określeniu ram początku i końca pracy, ile na wskazaniu podobieństw między zbliżonymi do siebie - pod wybranymi, kluczowymi kryteriami - zadaniami.
Porównywanie, szacowanie, o czym szerzej pisaliśmy w naszym artykule, rekomendowanym powyżej, jest dla człowieka bardzo naturalne.
Dostrzegamy analogie w sposób oczywisty, potrafimy dzięki ich dostrzeganiu dokonywać predykcji.
I trzeba przyznać jesteśmy w tym całkiem nieźli. Ta wrodzona, ale i rozwijana w toku rozwoju gatunkowego i osobniczego umiejętność, pozwala nam uzyskiwać znaczną trafność estymacji.
Story Points to technika, która wyrasta z tych naturalnych predyspozycji człowieka. Pozwala oszacować, kiedy można spodziewać się rezultatów, przy czym dokonuje tego nie za pomocą konkretnych miar czasowych, tylko za pomocą punktów fabularnych.
Nie tyle pozwala określić datę, co wskazuje prędkość, z jaką zaległości w Backlogu Produktu zostaną ukończone. Przy czym od razu mocno to podkreślmy, że punkty fabularne nie dają się sprowadzić do czasu.
Punkty Fabularne, Story Points są miarą prędkości, nie czasu wykonania.
Story Points Scrum - czym są Punkty Fabularne?
Story Points na gruncie Agile / Scrum są rozumiane jako jednostki miary, których używa się do oszacowania wysiłku wymaganego do ukończenia Historyjki Użytkownika, która może być na przykład nową funkcjonalnością lub aktualizacją funkcjonalności już zaimplementowanej.
Story Points są definiowane w odniesieniu do:
- złożoność zadania
- ilości pracy
- niepewności pracy.
Punkty Fabularne, Story Points są wykorzystywane w czasie Sprint Planningu i/lub Groomingu.
Mówiąc nieco jeszcze inaczej, a bazując na tym, czym są Historyjki Użytkownika w Agile i Scrumie, stanowią one rodzaj metryki.
Pozwalają określić jak łatwo / trudno będzie zaimplementować daną Historyjkę Użytkownika (User Story Scrum).
Dzięki wartości liczbowej, która jednak - jak podkreślaliśmy - nie stanowi reprezentacji czasu, pozwalają określić poziom trudności.
Punkty Fabularne są miarami abstrakcyjnymi, ale użytecznymi jednocześnie. Historyjka Użytkownika, której przypisany 3 punkty jest dwa razy prostsza do wykonania niż Historyjka, której przypisano 6 punktów.
Jak łatwo już dostrzec Punkty Fabularne, Story Points określają wysiłek, prędkość oraz dystans, jaki dzieli jedno zadanie od drugiego.
Wprawdzie nie dają odpowiedzi na pytanie - Kiedy spodziewać się końca implementacji? - ale za to pozwalają spojrzeć na proces, pracę, efekty z bardziej wielowymiarowej perspektywy.
Punkty Fabularne, Story Points to miary uwzględniające złożoność zadania, wysiłek konieczny do jego wykonania, ryzyko, jakie mu towarzyszy.
Są tym samym o wiele bardziej kompleksowe niż czas, który wskazuje, operuje tylko jedną wartością.
Story Points odwołują się do:
- ryzyka, bowiem projekty zwinne zawsze wiążą się z dużą zmiennością wymagań, uwarunkowań, tym samym są problematyczne pod względem estymowania
- złożoności, której konsekwencje, uwarunkowania są znane z teorii i jeszcze bardziej z praktyki - przy czym nie chodzi tylko o złożoność w sensie technologicznym, czysto programistycznym, ale także złożoność zarządzania projektem
- doświadczenia, powtarzalności zadań (np. zaimplementowanych funkcji), co jednocześnie daje wyobrażenie o ich problematyczności, prostocie, ale także uciążliwości (np. konieczny do uwzględnienia efektu monotonii, “taśmowości” pracy, która choć prosta może być wykonywana dłużej z racji właśnie na ten efekt).
Story Points pozwalają jednocześnie odpowiedzieć na pytania:
- Czy Sprint będzie mógł być efektywnie przeprowadzony?
- Czy zespół scrumowy dysponuje wszystkimi niezbędnymi informacjami do jego skutecznego przeprowadzenia?
- Czy Historyjka Użytkownika została optymalnie podzielona?
Warto jeszcze dodać, że na ostateczny efekt składają się czynniki, determinanty losowe (np. nieoczekiwane wydarzenia w postaci awarii, absencji w pracy, zmiany składu osobowego zespołu scrumowego).
Podsumowując:
Punkty Fabularne to metryka używana w zwinnym zarządzaniu projektami i programowaniu w celu oszacowania trudności wdrożenia danej Historyjki Użytkownika.
Jest to liczba, która informuje zespół o poziomie trudności Historyjki Użytkownika. Przy czym ową trudność rozumie się wielowymiarowo, jako cechę odnoszącą się złożoności, ryzyka i wysiłku.
Punkty Fabularne to rodzaj estymacji względnej, która jest najczęściej dokonywana podczas sesji Sprint Planningu i/lub Groomingu Backlogu Produktu.
Dlaczego zespoły zwinne powinny używać Punktów Fabularnych?
Przede wszystkim korzystanie z tej techniki jest dwustronnie korzystne. Stanowi realną wartość dla zespołów scrumowych, jak również właścicieli produktów (Product Ownerów).
Story Points zespołom scrumowym pozwalają:
- precyzyjniej zrozumieć zakres oczekiwań
- trafniej planować i efektywniej wdrażać
- wypracować stałe, optymalne tempo wdrażania, które gwarantuje satysfakcjonujący przebieg projektu
- szacować bez konieczności pracy pod presją czasu.
Z kolei Product Ownerom, Story Points pozwalają:
- uzyskać satysfakcjonujący zwrot z inwestycji
- uzyskać satysfakcjonujący stosunek jakości do ceny
- lepiej rozumieć specyfikę tworzenia produktów cyfrowych, uwarunkowań, determinant
- trafniej prognozować długoterminowe wdrożenia funkcjonalności i aktualizacji produktu cyfrowego.
Co jeszcze ważniejsze, Story Points pozwalają uświadomić Product Ownerom, że odwoływanie się do jednej miary, choć jednoznacznej i rozstrzygającej, jest częstokroć mylące i zaburzające ogląd sytuacji.
Tym samym może powodować sytuacje podejmowania decyzji w odniesieniu do jednej zmiennej, której waga nie zawsze jest najcięższa, a rola nie zawsze jest priorytetowa.
Punkty Fabularne mierzą cały obraz, a z pewnością jego najważniejsze składowe - ryzyko, złożoność, niepewność - dzięki czemu umożliwiają bardziej efektywne planowanie Sprintów.
Punkty Fabularne są także “wrażliwe” na różnice występujące pomiędzy poszczególnymi członkami zespołu scrumowego, jak również są “wrażliwe” na specyfikę każdego członka zespołu developerskiego.
Ponadto, Punkty Fabularne wzmacniają zespoły, promują pracę zespołową, znoszą częstokroć mało skuteczną presję czasu i tym samym zwiększają produktywność zespołów scrumowych.
W jaki sposób oblicza się Story Pointy?
W obliczaniu Punktów Fabularnych niezwykle istotne jest, by w proces ten zaangażowani byli wszyscy członkowie zespołu.
Od developerów, po testerów i specjalistów odpowiedzialnych za wdrożenia.
Istotą Punktów Fabularnych jest globalna perspektywa, która pozwala dostrzec i oszacować całkowity wysiłek konieczny do zaimplementowania danej funkcjonalności.
Stąd też w czasie obliczania Punktów Fabularnych konieczne jest ustalenie:
- złożoności pracy
- ilości pracy
- możliwości technologicznych, kompetencyjnych zespołu
- zagrożeń oraz obszarów niepewności
- narzędzi, warunków umożliwiających rozpoczęcie pracy
- ewentualnych kwestii problemowych, krytycznych
- znajomości implementacji danej funkcji i związanych z tym problemów, ryzyk.
Najczęściej Punkty Fabularne są przypisywane na konkretnie wskazanych spotkaniach za pomocą różnorodnych technik, które są preferowane przez dany zespół.
Typowe spotkanie, na którym dokonuje się estymacji obejmuje:
- dyskusję nad danym elementem z Backlogu Produktu
- ustalenie macierzy estymacji, w której uwzględnia się ryzyka, powtórzenia i złożoności
- wskazanie szacunków przez członków zespołu
- wartości skrajne poddawane są dyskusji, negocjacji, której ostatecznym celem jest uzyskanie konsensusu.
Punkty Fabularne najczęściej będąc wartościami abstrakcyjnymi mogą być wyrażone za pomocą różnych technik i skal.
Najczęściej do określenia wartości Punktów Fabularnych używa się techniki:
- ciągu Fibonacciego (Fibonacci Sequence)
- klasycznego ciągu liniowego - 1, 2, 3, 4…
Obliczając Punkty Fabularne trzeba pamiętać, że mają one względny charakter. Wartość numeryczna ma sens nie tyle liczbowy, co reprezentuje trudność.
Wartość 1 reprezentuje zadanie najłatwiejsze, bez względu na rodzaj projektu, rodzaj, specyfikę Historyjki Użytkownika.
Dwukrotność wartości podstawowej - 2 - reprezentuje dwukrotnie większą trudność zadania. Trzykrotność wartości podstawowej - 3 - reprezentuje trzykrotnie większą trudność zadania.
Trafność szacunków w dużej mierze wynika z doświadczenia w implementacji danej funkcji oraz doświadczenia w samej estymacji.
Przykładowo, stworzenie strony kontaktu z polami formularza kontaktowego zawierającego 3 pola i drugiej strony, analogicznej, jedynie różniącej się ilością pól kontaktu, a wymagającej 9 pól nie jest trzykrotnie bardziej złożone, pracochłonne.
Nie jest także znacząco różne pod względem złożoności, nie jest trzykrotnie bardziej złożone, czy trzykrotnie bardziej ryzykowne.
Różnica nie ma charakteru zasadniczego, a jedynie odnosi się do wąskiego zakresu.
Jest raczej oczywiste, że jeśli zadaniu wykonania pierwszej strony przypiszemy wartość 2 Story Pointów, to drugiemu nie przypiszemy wartości 6 Story Pointów, bowiem taka różnica między nimi byłaby po prostu nierealistyczna. Lub mówiąc precyzyjniej nieadekwatna.
Estymując Punkty Fabularne zawsze należy pamiętać, że wspólnym mianownikiem dla zsumowanej ilości pracy, ryzyka, złożoności, niepewności jest wysiłek.
To wysiłek związany z konieczną do wykonania pracą, włożony w przeciwdziałanie ryzyku, pokonaniu złożoności, zredukowaniu niepewności stanowi clue techniki Punktów Fabularnych w Agile / Scrum.
Czym są Scrum Story Points. Podsumowanie
- Estymacja pracy w Scrum User Story jest dość kłopotliwa.
- Umiejętność dokonywania możliwie najbardziej trafnej, bliskiej prawdy estymacji czasu pracy jest niezbędna, by projekt zakończył się sukcesem.
- Czas, choć może wydawać się obiektywny, bezstronny, łatwo porównywalny, niekoniecznie jest bezproblemowy, jako narzędzie służące do estymacji.
- Bezwzględne metody szacowania (np. czasowe) nie zawsze są najbardziej skutecznymi.
- Story Points na gruncie Agile / Scrum określają wysiłek, prędkość oraz dystans, jaki dzieli jedno zadanie od drugiego.
- Story Points to miary uwzględniające także złożoność zadania oraz ryzyko, jakie mu towarzyszy.
- Story Points pozwalają uświadomić Product Ownerom, że odwoływanie się do jednej miary, choć jednoznacznej i rozstrzygającej, jest częstokroć mylące i zaburzające pełen ogląd sytuacji.
- Punkty Fabularne są “wrażliwe” na różnice występujące pomiędzy poszczególnymi członkami zespołu scrumowego, jak również na specyfikę każdego członka zespołu developerskiego.
- Najczęściej do określenia wartości Punktów Fabularnych używa się ciągu Fibonacciego (Fibonacci Sequence), klasycznego ciągu liniowego - 1, 2, 3, 4.
