Prowadząc szkolenia kształcące Scrum Masterów czy Product Ownerów, wiele razy spotkaliśmy się z niezrozumieniem i wątpliwościami podczas omawiania zagadnienia, jakim jest Story Point. Postanowiłem więc w poniższym artykule wyjaśnić, dlaczego jest ono tak ważne w procesie zarządzania projektami.
Udostępnij!
Story Points – krótka historia o tym, dlaczego warto je stosować.
Czym jest Story Points?
Na szkoleniach z metodyk zwinnych w Altkom Akademii uczymy w jaki sposób korzystać z metody Story Point, uznając ją za integralną część całego procesu zarządzania projektem. Wiele zespołów podczas dostarczania produktu używa jej do estymowania pracy, którą trzeba wykonać w kolejnej iteracji. Product Ownerzy korzystają ze Story Points do przygotowania budżetu oraz opracowania scenariusz będących odpowiedzią na najczęściej zadawane pytania o czas oraz koszty realizacji danych rozwiązań. Wydawać by się mogło, że zarządzając projektami już od dawna zajmujemy się estymowaniem, kreśleniem ścieżek krytycznych czy wypełnianiem wykresów Gantta, w związku z zachodzącymi w biznesie zmianami wydają się one jednak niewystarczające. Wiele rzeczy ma dziś wirtualną, niedookreśloną, płynną i globalną postać, która wymaga od zespołów zastosowania podejścia zwinnego. Story Points to miernik służący do pomiaru wielkości wpływającej na wydajność zespołu. Choć wielu osobom mogłoby się tak wydawać, nie jest to żadna magiczna formuła, tylko weryfikowalna jednostka określająca obiektywne informacje na temat zadania, które ma być wykonane.
Dlaczego ich używamy?
Następna warta omówienia kwestia to powody, dla których używamy Story Points. Są one związane głównie ze stosowanymi przez ludzi procesami poznawczymi i ich specyfiką. Posłużmy się tutaj przykładem. Zadając pytanie o objętość dzbanka, który właśnie pojawił się na stole, oczekiwałbym zróżnicowanych odpowiedzi, zarówno jeśli chodzi o samą liczbę, jak i użytą jednostkę. Estymując za pomocą metod absolutnych z reguły nie jesteśmy w stanie dokładnie oszacować wyniku. W sytuacji, gdyby obok wspomnianego dzbanka pojawił się na stole drugi, dwa razy większy, i zadano by to samo pytanie, z dużym prawdopodobieństwem znaczna część odpowiedzi odsyłałaby do pierwszego z nich. Estymowanie porównawcze jest dla ludzi bardziej dostępne niż absolutne. Nasze szacunki są znacznie dokładniejsze, gdy posiadamy jakiś punkt odniesienia. Zarządzając projektami, coraz częściej spotykamy się z zadaniami, które wykonujemy po raz pierwszy lub które są nieokreślone i ryzykowne. W jaki więc sposób je estymować? Estymując deterministycznie, czyli na przykład za pomocą jednostki czasu, ryzyko pomyłki jest wysokie. Dodatkowo w organizacjach takie estymaty bardzo często są traktowane jako obietnice, co rodzi problemy w przypadku niewywiązania się z nich.
Jakie jest więc rozwiązanie?
Story Points to miernik, który nie ma jednostki. Z tego powodu jest on uniwersalny. Kolejną zaletą jest jest jego wieloznaczność. Jeden Story Point może mieć wiele znaczeń dla różnych zespołów, ale co do zasady panuje zgodność co do samego miernika. Z tego też powodu, nie powinno się dopuszczać do dużej fluktuacji w zespołach Agile. Story point mierzy nakład pracy potrzebny do spełnienia Definition of Done dla historyjki będącej przedmiotem estymowania. Pamiętać jednak należy, że nakład pracy to nie to samo, co czas. Na to, ile pracy należy włożyć w zadanie mają wpływ trzy czynniki:
- Stopień skomplikowania zadania – warto rozłożyć poszczególne taski na czynniki pierwsze i określić poziom ich złożoności. Poznając dokładny zakres, będziemy mogli lepiej oszacować czas potrzebny na jego wykonanie.
- Ryzyko – warto rozpatrzyć wszelkie możliwe sytuacje, które mogą spowodować komplikacje i generować problemy, a następnie zastanowić się nad ewentualnymi rozwiązaniami, które można by zastosować w celu naprawy błędów.
- Ilość pracy – tutaj należy określić dokładną listę zadań i oszacować czas spędzony na ich wykonaniu.
W jaki sposób stosować Story Points?
Na pewnym etapie szkoleń Scrum Master czy Product Owner pojawia się zazwyczaj sporo pytań i wątpliwości dotyczących stosowania Story Points w praktyce.
Story point to miernik relatywny, co oznacz tyle, że żeby z niego korzystać potrzebujemy punktu odniesienia. Podobnie jak z dzbankiem – by określić pojemność drugiego potrzebowaliśmy pierwszego. Jak go zdobyć? Metod jest kilka. Najczęściej tworzy się tak zwaną historyjkę odniesienia (ang. Reference story). Powinna być relatywnie krótka i prosta, aby łatwo było określić, ile będzie miała punktów. Najczęściej takiej historyjce przydziela się 1 lub 2 punkty.
Mając punkt odniesienia podczas estymacji kolejnej historyjki, należy zastanowić się czy różni się ona od referencyjnej. Jeżeli tak, to ile razy jest „większa”? Jeżeli 10 razy większa, przyznajesz jej 10 razy więcej punktów. W momencie, gdy dysponujesz już dobrze określonymi historyjkami czy PBI (product backlog item), możesz przejść do triangulacji.
Kiedy nie używać Story Points?
Choć Story Poins są bardzo użyteczne, w niektórych sytuacjach mogą nie przynieść oczekiwanych rezultatów. Moim zdaniem nie sprawdzą się, gdy:
- członkowie zespołu pracują nad różnymi produktami
- organizacja lub klient upiera się by mierzyć czas
- zespół jest nieliczny (poniżej 3 deweloperów)
- zespół często się zmienia
- nie stosujesz cyklów o stałej długości w swoim projekcie
Ciąg dalszy nastąpi…
Używanie Story Points wymaga praktyki, ale mam nadzieję, że ten artykuł przybliżył nieco jego specyfikę. Oczywiście jest jeszcze kilka istotnych kwestii dotyczących Story Points, których nie poruszyłem, m.in. jak ich używać do mierzenia velocity czy jak budować budżet projektu za pomocą tego miernika. Po odpowiedzi zapraszam do sali wykładowej, gdzie podczas naszych szkoleń zgłębiamy ten temat.
Jak zwykł mawiać Adam Weisbart: Stay Agile, Never change.
