Jak to się robi w Story Point’ach

Jeżeli używamy tradycyjnych metod rozwoju oprogramowania, najczęstszą jednostką szacowania pracy jest osobodzień, osobogodzina czy osobomiesiąc. Przy szacowaniu jakichś zmian czy projektów możemy usłyszeć: „ta zmiana to trzy dni pracy” lub „ten projekt to pięć miesięcy pracy dla jednej osoby”.

Jeżeli wprowadzamy w organizacji metody zwinne, to prędzej czy później zjawia się jakiś TrueAdżajMaster, który mówi: „proszę państwa, osobodni są już passe, to jest przestarzały waterfall, prehistoria i epoka kamienia łupanego, prawdziwy AdżajDeweloper szacuje wyłącznie w Story Pointach!”

Co to jest ten Story Point?

Tak się składa, że nie ma jednej, kanonicznej definicji co to jest ten Story Point. W różnych źródłach można przeczytać takie określenia:

• A story point is a metric used to determine (or estimate) the difficulty of implementing a given story.
• Story point is used to measure the effort required to implement a story.
• In simple terms its a number that tells the team how hard the story is. Hard could be related to complexity, unknowns and effort.
• Story point is team-specific units of relative size used in estimating requirements.

Przyjmijmy dla potrzeb naszego artykułu, że Story Point jest to miara pracy, którą zespół musi wykonać, żeby wykonać dane zadanie.

TrueAdżajMaster zazwyczaj nie poprzestaje na wprowadzaniu koncepcji Story Points, ale tłumaczy natychmiast, dlaczego są one tak ważne.

Zazwyczaj pierwszy argument mówi o tym, że ludzie lepiej radzą sobie z porównywaniem rzeczy ze sobą niż z szacowaniem w jednostkach bezwzględnych. Łatwiej jest porównać czy Kasia jest wyższa od Basi niż podać dokładny wzrost Kasi w centymetrach.

Drugi argument na rzecz Story Points brzmi tak: szacowanie w punktach sprawia, że szacowania nie są zależne od tempa pracy zespołu. Dla przykładu: zadanie, z jakim mierzy się zespół po raz pierwszy, zostanie przykładowo wycenione na 5 Story Points. Zespół będzie pracował nad nim 3 dni. Kiedy to zadanie powróci, a warunki pozwolą na powtórzenie czynności, schematów, kroków wykonanych poprzednio – to zadanie nadal będzie miało wielkość 5 Story Points, ale wykona się je w dwa dni. Wielkość zadania zostaje ta sama – ale zespół działa szybciej.

Trzeci argument to fakt, że wielkość zadania w punktach jest to wielkość pracy dla zespołu. Czyli nie powinniśmy już usłyszeć, tłumaczenia typu „szacowanie na dwa dni to robił Franek, ale Franka teraz nie ma, a nam to zajmie teraz trzy razy dłużej…”. Jak zespół mówi że zajmie to X dni czy punktów, to zespołowi ma to tyle zająć, kropka.

Czwarty argument to gra w Planning Pokera. A przecież każdy woli grać w pokera niż spinać się nad wymyślaniem pracochłonności zadań, prawda?

Jak zatem może wyglądać w stosowanie Story Points w praktyce?

Krok 1 – określ i jasno ogłoś cel używania Story Points

Pierwszą rzeczą, którą trzeba zrobić, jest określenie i ogłoszenie zespołowi, po co w ogóle te punkty są. Jest to szczególnie ważne w przypadku zespołów, które wcześniej używały jednostek typu osobodzień. Dla nich wprowadzenie szacowania w punktach jest zmianą – a każda zmiana, której celu nie znamy, budzi naszą nieufność.

Dlatego ważne jest powiedzenie, że celem używania Story Points nie jest podniesienie efektywności zespołu, nie jest podążanie za modą, nie jest to badanie efektywności pracy poszczególnych osób ani nie jest to nowa nazwa na dniówki.

W naszym przypadku używanie Story Points ma wyłącznie jeden cel – chcemy jak najlepiej trafić z ilością zadań, które bierzemy do sprintu w trakcie planowania. Jeżeli weźmiemy za dużo zadań – nie wyrobimy się z robotą i na przeglądzie sprintu będzie wstyd. Jeżeli weźmiemy za mało – trzeba będzie dobierać kolejne i zawracać głowę Product Owner’owi, a po co. Najlepiej wziąć tyle, żeby móc przez cały sprint pracować w równym tempie i zakończyć wszystkie zadania w terminie. Story Points to technika, która ma nam pomóc w tym szacowaniu ile zadań zmieści się do sprintu. I nic więcej.

Krok 2 – zdefiniuj zadanie referencyjne

Jak już mamy cel, dobrze jest zdefiniować „wzorzec metra” – czyli zadanie referencyjne, do którego będziemy odnosili pozostałe zadania. Wydaje się to proste, lecz w praktyce zdarzają się tu spore kłopoty. Problemem może być na przykład duży rozrzut kompetencji członków zespołu – jeżeli jedna osoba specjalizuje się w zmianach na bazie danych, a druga w JavaScripcie, to trudno będzie wymyślić dla nich wspólne, zrozumiałe zadanie.

Zadaniem referencyjnym, którym posługujemy się obecnie w naszych zespołach, jest wdrożenie prostej zmiany na środowisko produkcyjne. Nie definiujemy, czym jest „prosta zmiana” – przyjmujemy że jest  to zmiana, która jest na tyle trywialna, że można ją wdrożyć bez zaawansowanych testów. Kosztem zadania referencyjnego jest wykonanie tej zmiany, prosty „smoke test”, odpowiedni commit czy też push, krótki opis zmiany, przejście workflow’u służącego do przeniesienia się tej zmiany na produkcję. To wszystko wyceniamy np. na 3 Story Points – a inne zadania odnosimy do tej miary. Zadania prostsze dostają 0, 1, czy 2 punkty; zadania trudniejsze – 5, 8, 13 lub więcej.

Krok 3 – mierz Velocity

No dobrze. Mamy jakiś backlog zespołu, który prezentuje listę zadań, które mają określoną wielkość.

Skąd teraz mamy wiedzieć, ile zadań wziąć do sprintu? Gdyby szacowanie było w dniach pracy, to byśmy wyliczyli ile dniówek jest w sprincie i byłoby wiadomo. A tak?

TrueAdżajMaster mówi tutaj tak: „weźcie tyle, ile uważacie za słuszne. Przed następnym sprintem będziecie wiedzieli czy wzięliście za dużo, czy też za mało. Jak zaczniecie mierzyć i zapisywać sobie, ile punktów zrealizowaliście w kolejnych sprintach, to ze sprintu na sprint będziecie coraz lepiej wiedzieć, ile zadań jesteście w stanie wziąć do kolejnych sprintów”.

A jak to wygląda w praktyce? Praktyczny wykres Velocity w jednym z zespołów wygląda tak:

Niebieska linia obrazuje planowaną ilość punktów na każdy sprint. Czerwona – ilość punktów dla ukończonych zadań. Widać, że początkowym okresie zespół planował sporo, ale nie wszystko udawało się skończyć. Dopiero od sprintu nr 9 czerwone i niebieskie linie zaczynają się pokrywać. Widać również, że czerwona linia powoli wzrasta – zespół powoli uczy się dostarczać coraz więcej.

Zastanawiać na tym wykresie może spadek planowanego Velocity podczas sprintu nr 14. Wyjaśnienie tego jest proste – zespół wtedy wiedział, że część osób będzie nieobecna w pracy podczas sprintu i zaplanował sobie mniej pracy. Także zapisując sobie Velocity w jakimś narzędziu, dobrze jest też móc dodawać tam notatki – co specyficznego wydarzyło się, że w danym sprincie udało się wykonać więcej lub mniej pracy.

Krok 4 – przygotuj się na zmiany…

Planowanie jest proste na papierze… Po zaplanowaniu i po starcie sprintu, prędzej czy później ktoś ze zespołu przyjdzie do TrueAdżajMastera i padnie takie zdanie: „Słuchaj, zaplanowaliśmy zadanie X na 3 punkty, ale jak się za nie zabraliśmy, to wychodzi raczej 8. Czy możemy zwiększyć pracochłonność tego zadania?”. Ewentualnie „Musieliśmy szybko wykonać dodatkowe zadanie Y, koszt to jakieś 2 punkty, czy możemy dopisać to zadanie do Velocity wykonanej w naszym sprincie?”.

Aktualizować koszt zadań podczas sprintu czy nie? Wszystko zależy od tego, jaki cel chcemy osiągnąć. Jeżeli aktualizujemy koszt, to oznacza, że estymata kosztu wyraża aktualnie znany koszt zadania. Jeżeli nie aktualizujemy – estymata wyraża szacowanie zadania z momentu planowania sprintu.

Osobiście przekonuje mnie jeden argument za tym, żeby po starcie sprintu nie zmieniać już estymat. Sprint jest bowiem pewnego rodzaju umową między zespołem a Product Owner’em. Product Owner deklaruje, że nie będzie zespołowi przeszkadzał nowymi zadaniami. Zespół deklaruje, że zrobi wszystko, żeby zakończyć zadania wzięte do sprintu w terminie. Aktualizacja kosztu zadania może być wytrychem do tego, żeby jakiś zadań nie zrobić. „Drogi PO, deklarowaliśmy, że dowieziemy zadania za 20 punktów, ale sam tylko zobacz, jedno z tych zadań spuchło i teraz mamy już 27 punktów do zrobienia. No sam przecież widzisz, że tego nie da się zrobić w tym czasie…”.

Brak aktualizacji estymat w sprincie mówi zespołowi jedno – jak wyestymujesz, tak będziesz potem pracować. Jeżeli pomyliłeś się i dałeś za małą estymatę – trudno, ona już taka zostanie, trzeba będzie więcej zasuwać. Następnym razem spróbuj oszacować lepiej.

Karty, obawy, doskonalenie

I na kilka uwag praktycznych na koniec.

Bardzo polecam inwestycję w karty do gry w planning pokera. Używaliśmy kiedyś aplikacji na telefon. To nie to samo. Przebieranie w swoich kartach w poszukiwaniu właściwej, wykładanie kart na stół, zastanawianie się, co kryje zakryta karta z szacowaniem kolegi – żaden telefon nie zapewnia takiego doświadczenia…

Często menedżerzy wyrażają obawę: „a jeżeli zespół będzie brał do sprintu mniej zadań, po to żeby się nie przepracować?”. Możliwości tutaj są dwie. Jeżeli mamy zmotywowany zespół, który lubi to co robi i którego cieszą rezultaty pracy – to taki zespół będzie brał zadania „pod korek”. Natomiast jeżeli mamy zespół, który ponad rezultaty pracy przekłada spokojne wypicie kawy i czas na przeczytanie gazety – wtedy oddanie zespołowi odpowiedzialności za szacowanie pokaże to zjawisko.

Niesamowicie ogląda się proces doskonalenia przez zespół procesu szacowania zadań. Początkowo zadania szacowane są szybko. Z biegiem czasu przy szacowaniu pojawia się coraz więcej dyskusji oraz ważnych pytań: „a co jeżeli będzie musiała to robić osoba, która nie zetknęła się z tym kodem?”, „a czy mamy wszystkie potrzebne informacje?”, „czy nie potrzebujemy tutaj czegoś od innego zespołu?”

To co jest w końcu lepsze?

Są dwie słabości szacowania za pomocą Story Points. Pierwsza z nich jest zawarta w jednej z definicji na początku artykułu – Story Points to „team-specific units”. Jeżeli nie mamy stałych zespołów, jeżeli zespoły szybko się zmieniają, jeżeli nie realizujemy zadań zespołowo lecz indywidualnie – to wówczas szacowanie za pomocą punktów działa słabo.

Drugą słabością jest to, że Story Points są empiryczne – dopiero po kilku sprintach mamy w miarę wiarygodne przełożenie wielkości zadania w punktach na czas pracy zespołu.

Szacowanie w osobodniach jest pozbawione tych dwóch wad – osobodniówki są miarą uniwersalną. Co więcej, Manager może od razu umieścić tę miarę w planie projektu, zrobić wykres piękny Gantta z datami oraz wyliczyć koszt projektu.

Ale główną miarą jakości szacowania jest tak naprawdę to, na ile dobrze to szacowanie przybliża rzeczywistość. Lepsza jest ta metoda, której rezultat będzie bardziej zbliżony do rzeczywistości. Niestety nie znam nikogo, kto porównywałby ze sobą praktyczną skuteczność obu metod. Być może kiedyś w zespole zrobimy taki eksperyment…

A ty czego używasz do szacowania – dniówek czy punktów?