Estymacja czasu pracy jest niezwykle ważna bez względu w jakim projekcie bierzemy udział. W moim przypadku, branża IT, jest to wyjątkowe ważne, bo od tego będzie zależało czy uda się dowieść daną funkcjonalność na produkcję i spełnić oczekiwania biznesu. Pracując w metody Scrum z pomocą przychodzą nam Story Pointy.
Problem z czasowym estymowaniem czasu
W idealnym świecie biznes chciałby wiedzieć dokładnie na kiedy będzie coś zrobione. Wiecie, trzeba zaimplementować nowy ficzer, który znajduje się w backlogu, i chcemy oddać go w ręce klienta za tydzień. Czy to się uda? Odpowiedź może być jedna: no zależy. Czynników wpływających na sukces jest wiele, zarówno tych związanych jak i nie związanych.
Standardem niektórych kierowników czy produkt ownerów/managerów jest dodanie określnego czasu x. Chodzi o to by mieć pewien bufor w razie niespodzianek. Ile wynosi x? Tego nikt nie wie. Wszystko zależy od zespołu, natłoku pracy itp.
Jak widzicie, estymowanie zadań (dokładne) w czasie jest trudne. Jest wiele niewiadomych.
Estymowanie relatywne w Story Pointach
Dlatego alternatywą w estymowaniu zadań w czasie jest estymowanie relatywne w Story Pointach (SP). Niemal w każdym projekcie IT estymacja w SP jest standardem. Tutaj nikt nie pyta o czas tylko o story pointy. Estymowanie to część pracy programisty.
– Ile SP na to zadanie?
Wartości Story Pointów, czyli ciąg Fibonacciego
Przyjęło się, że wartości SP są liczbami z ciągu Fibonacciego. Czyli: 1, 2, 3, 5, 8, 13, 21, itd., czyli każda następna wartość jest sumą dwóch poprzednich liczb. Dzięki temu łatwo zauważyć różnicę pomiędzy jednym zadaniem a drugim. W praktyce (na podstawie podanych przeze mnie liczb) liczba 1 oznacza coś bardzo prostego zaś 21, to problem do rozwiązanie potrzebna będzie duża liczba tęgich głów.
Z doświadczenia wiem, że wartością maksymalną jest 34 (13+21). Potem często pojawia się znak nieskończoności (∞). Czasami też w zespołach pojawia się wartość ½, która jest zarezerwowana dla naprawdę banalnych zadań.
Skąd wiedzieć jakie wartości SP przypisać do zadania?
I tutaj zaczyna się cała „zabawa”. Podczas sesji planowania (ang. sprint planning) czy refinamentu/groomingu zespół bierze zadania z backlogu i każdemu z nich przypisuje wartość SP. Aby dobrze wycenić zadanie (ang. task) musimy wziąć pod uwagę następujące czynniki:
- złożoność problemu,
- zależności,
- niewiadomie.
To wszystko składa się na wysiłek jaki trzeba wykonać by ukończenie zadania. Dobrą praktyką jest odnoszenie się do innego zadania celem dokładniejszej estymacji. Nad estymacją pracuje cały zespół. Każdy może wyrazić opinię na temat danego zadania, podważyć wycenę zadania.
Skąd wiadomo ile Story Pointów można wziąć do sprintu?
Z pomocą przychodzą dane historyczne. Każdy członek zespołu może brać różną liczbę Story Pointów. To ile punktów można brać do sprintu zależeć będzie od średniej branej z kilku ostatnich sprintów. Wartości te mogą się oczywiście zmieniać zarówno w górę jak i w dół. Czasem okaże się, że jakieś zadanie zostało niedoszacowane a inne przestrzelone.
Story Pointy a czas
Wielu managerów a nawet członków zespołu próbuje przeliczać SP na czas. Jest błąd. Nie da się tego przeliczyć w żaden sposób. Pierwszy argument jaki przychodzi mi do głowy, to doświadczenie osoby z zespołu. To samo zadanie wycenione na np. na 2 SP może zająć inną jednostkę czasu różnym osobom.
