Story point – rewolucja w estymacji zadań? cz. 1

Nowa idea

Odkąd pojawiła się idea szacowania wymagań projektowych w sposób oderwany od klasycznych man days, wiele osób sceptycznie podeszło do porzucenia utartych szlaków. Oprócz siły nawyku i prostej logiki, przeciwko zmianie podejścia na tzw. story points (punkty historyjek użytkownika) pojawiały się głosy braku możliwości przeliczenia punktu na pieniądze czy kontroli czasu pracy na podstawie story points. Przeciwnikom nie można odmówić racji. Przeliczanie abstrakcyjnych jednostek użytych do szacowania nie jest ani oczywiste ani proste, tak samo jak tradycyjne pojmowanie zwierzchnictwa i kontroli, które w Scrumie nie występują.

Wadliwe szacunki

Po co więc rezygnować z dotychczasowych, sprawdzonych według managerów, sposobów rozliczania zadań? Co jest nie tak z szacowaniem pracochłonności w dniach/godzinach?

Obie jednostki (man days oraz story points) są dobre, jednak odnoszą się do innych wartości a co za tym idzie, w określonych sytuacjach mogą dawać odmienne korzyści. Warto zdawać sobie sprawę, że szacowanie za pomocą czasu posiada jednak pewne wady, o których poniżej.

Po pierwsze, estymacja oparta o konkretny czas, pozwala wyliczyć koszt pracy z dokładnością do złotówki. Ta precyzja bywa jednak pułapką. Określenie dokładnych estymat projektu, przed jego rozpoczęciem może być obarczone dużym błędem. W nieznanej organizacji, w nowym zespole oraz na wymaganiach dotyczących nowego systemu – jest to niezwykle trudne. Jeżeli dodamy do tego sztywny budżet projektowy lub model rozliczenia typu fixed price, nasze poczucie kontroli jest zwyczajnie iluzoryczne.

Po drugie, “czyste” szacunki w dniach roboczych nie bierze pod uwagę wielu czynników, które mogą się wydarzyć. Część z nich da się przewidzieć np. typowe ryzyka projektowe, zmianę sposobu implementacji wymagań czy zaplanowane urlopy, części jednak nie przewidzimy. Szacowanie pracochłonności w dniach określa jeden, konkretny wariant przebiegu pracy. Ewentualne narzuty są zazwyczaj mało precyzyjne, czasem parametryzowane, ale najczęściej zależne od subiektywnej oceny estymującego.

Po trzecie, szacunki czasowe nie funkcjonują w próżni. Zawsze posiadają punkt odniesienia. Wybrana osoba porównuje szacowane zadanie do zadań wykonywanych w przeszłości i poprzez analogię, określa czas potrzebny na ich realizację. Mówiąc obrazowo – doświadczony lider zespołu wie, że dane zadanie jego zespół wykonywał w dwa dni, więc taką “wycenę” przyjmuje w obecnym projekcie. Rzeczywistość może okazać się zupełnie inna.

Kontrola, która wynika z dokładnego pomiaru czasu, bywa często nadużywana. W projekcie można spotkać wiele patologii m.in. wymuszanie dostarczenia elementu po pierwszych kilku dniach, tworzenie sztucznej rywalizacji między zespołami czy wymuszanie zaniżania estymat. Taki mikro management, podsycany szacowaniem pracy w jednostkach czasu, nie ma w Scrumie najmniejszego sensu. Rujnuje atmosferę w zespole i świadczy o słabym przygotowaniu managera do swojej roli.

Alternatywa

Dla osób nie mających doświadczenia ze zwinnymi metodykami zarządzania (Agile), warto wyjaśnić, czym są story points czyli punkty historyjek użytkownika. Mike Cohn – jeden z ojców Scruma, tak zdefiniował to pojęcie: “Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work.”

To co warto zapamiętać to informację, iż story points nie odnoszą się do czasochłonności zadania, a do jego rozmiaru! Moim ulubionym porównaniem obrazującym oderwanie rozmiaru zadania od czasu jego trwania jest przykład z jedzeniem pizzy: Mamy dwie osoby siedzące przy stole. Jedna z nich nie jadła nic od dwóch dni, druga, zjadła przed chwilą dwudaniowy obiad. Jeśli postawimy przed nimi dwie pizze to pomiar czasu wskaże, że druga osoba (najedzona) będzie jadła pizzę przez godzinę, zaś pierwsza (głodna), zje ją w dziesięć minut. To na czym skupia się story point to rozmiar pizzy, który w obu przypadkach jest taki sam.

Story point swoją nazwę zaczerpnął od formy wymagań, do których szacowania służy, czyli user stories (historyjek użytkownika). W dużym uproszczeniu, historyjka użytkownika to sposób formułowania wymagań produktu, z punktu widzenia wartości dla użytkownika końcowego, o określonej narracji i wymaganiach dotyczących podejścia do ich pisania. Jeśli chcesz dowiedzieć się więcej na ten temat to polecam książkę “User stories applied” autorstwa wspomnianego wyżej Marka Cohna.

Story point bez wad?

Wracając do przykładu z pizzą: po co nam wiedza o rozmiarze pizzy skoro interesuje nas jak szybko ktoś ją zje? Tak przedstawiona sprawa ma sens wtedy, gdy z góry wiemy, kto będzie wykonywał daną pracę, np. w sytuacji, gdy dany specjalista pracuje sam. W przypadku zespołu składającego się z trzech do dziewięciu osób (zalecenia Scrum Guide), posiadającego uzupełniające się kompetencje, wyliczenie z góry całego projektu, w oparciu o konkretne osoby, obarczone jest sporym ryzykiem.

Dzięki szacowaniu w story point najpierw określamy rozmiar zadania. Okres jego wykonania np. w ciągu jednego sprintu, definiujemy przy planowaniu sprintu, gdy członek zespołu podejmie się wykonania tej pracy. Mierzenie pracochłonności zamiast czasu lepiej określa ryzyka oraz zmiany decyzji. Story point oznacza relatywny rozmiar wyzwania. Taka perspektywa pozwala lepiej okiełznać zagadnienie ryzyk oraz niepewności.

W kwestii micromanagementu, user story oszacowane za pomocą story points i zaakceptowane przez zespół oraz właściciela produktu (ang. Product Ownera) jako część sprintu, tworzą zobowiązanie do wykonania tego zadania po stronie zespołu dopiero na koniec sprintu. Taka forma zobowiązania przesuwa ciężar odpowiedzialności na zespół i gwarantuje większą swobodę jego działania. Porównywanie prędkości dwóch zespołów, np. który dostarcza więcej punktów per sprint, jest bez sensu, bowiem punkt ma taką wartość, jaką nada mu dany zespół. Zespół A produkując 50 story point’ów per sprint, może wykonać taką samą pracę jak zespół B produkujący 12 punktów. Różnica wynika z tego, że zespół B za punkt odniesienia przyjął większą ilość pracy.

Story points stanowią atrakcyjną alternatywę szacowania czasowego. Wyjaśniłem różnicę między dwoma podejściami, które w praktyce są pojmowane w różny sposób. Prawidłowe zrozumienie zalet oraz podejścia do zwinnej estymacji nie oznacza jeszcze sukcesu w implementacji, uświadamia jednak czemu ta zmiana jest potrzebna.

Wdrożenie story points warto rozważyć z wielu powodów. Należy jednak pamiętać o takich elementach jak dojrzałość zespołu czy potencjalnych wadach tego podejścia. W drugiej części “Story point – rewolucja w estymacji zadań?” omówię w jakich warunkach punkty sprawdzają się lepiej, a w jakich gorzej. Poruszę także zagadnienie ścieżki krytycznej (Critical Path) w odniesieniu do story points.