Brak ocen Sprint Backlogu za pomocą Task Points

Kiedy w 2005 roku pisałem książkę Agile Estimating and Planning, zajmowałem się różnymi metodami szacowania już od pięciu lat. Po przeprowadzeniu eksperymentów z kilkoma zespołami – szczególnie z tymi, które pracowały bezpośrednio ze mną – czułem, że wiem już wystarczająco dużo, aby napisać tę książkę.

Mimo to wiele rzeczy wciąż pozostawało dla mnie niejasnych (i oczywiście nadal tak jest!). Dlatego szukałem zespołów, które szacowały i planowały swoje projekty inaczej niż ja. Niektóre z nich używały, obok Story Points, również Task Points do szacowania swoich Product Backlog Items.

To mnie zaintrygowało. W tamtym czasie byłem już zwolennikiem Story Points – a z biegiem czasu, dostrzegając ich zalety, stałem się jeszcze większym fanem. Nie mogłem jednak zrozumieć, dlaczego zespół miałby korzystać z Task Points. Ponieważ jednak tak bardzo ceniłem Story Points, chciałem dowiedzieć się więcej o zespołach pracujących z Task Points.

Udało mi się przekonać kilka zespołów, aby pozwoliły mi się obserwować i w ten sposób dowiedzieć się więcej.

To, co odkryłem, potwierdziło moje przekonanie, że zespoły nie powinny oceniać swoich Sprint Backlog Items za pomocą Task Points.

Główna zaleta Story Points

Główną zaletą Story Points jest to, że osoby o różnych umiejętnościach, poziomach doświadczenia i różnym tle mogą wspólnie szacować nakład pracy.

Posłużmy się nieco żartobliwym przykładem i wyobraźmy sobie, że chcę wspólnie z ośmiornicą oszacować, ile wysiłku wymaga umycie mojego samochodu.

Ośmiornica ma cztery razy więcej ramion niż ja. Oznacza to, że mogłaby umyć mój samochód cztery razy szybciej ode mnie. (Mówiłem, że to nie do końca poważny przykład. Ale poczekajcie.)

Ośmiornica będzie też każdy inny samochód myć cztery razy szybciej niż ja. Ośmiornica i ja możemy więc być może zgodzić się, że mój mały dwuosobowy kabriolet wart jest około pięciu Story Points, a nieco większy samochód – dziesięciu punktów.

Story Points pozwalają więc ośmiornicy i mnie wspólnie ustalić pewną liczbę punktów – nawet jeśli ośmiornica jest zdecydowanie szybsza ode mnie.

Task Points

Obserwując te zespoły, zauważyłem, że Task Point był w zasadzie tym samym co Story Point. Wszystkie zespoły, z którymi rozmawiałem, chciały jednak używać mniejszej jednostki niż Story Points.

Na przykład zespół, który wykonuje dziesięć Story Points na Sprint, mógłby osiągnąć około 80 Task Points na Sprint.

Zespoły po prostu chciały mniejszej i dokładniejszej jednostki, aby lepiej śledzić postępy. Przypomina to trochę sytuację, w której prędkościomierz w samochodzie pokazywałby prędkość w latach świetlnych na godzinę. W takim przypadku trudno byłoby mi ocenić, czy przestrzegam ograniczeń prędkości.

Używanie drobniejszych jednostek było dla wielu zespołów dobrym pomysłem. W końcu dość trudno jest mierzyć dzienny postęp zespołu za pomocą Story Points, jeśli np. realizuje on siedem Story Points w ciągu dwóch tygodni. W takim przypadku Story Points są po prostu zbyt dużą jednostką, aby być pomocne.

A co z godzinami?

Istnieje jednak już drobniejsza jednostka, z którą każdy członek zespołu jest dobrze zaznajomiony: godziny.

Obserwując zespoły szacujące za pomocą Task Points, zauważyłem, że nie ma w tym żadnej przewagi nad szacowaniem Sprint Backlog Items w godzinach.

Istnieje zasadnicza różnica między Product Backlog Items (zazwyczaj w formie User Stories) a Sprint Backlog Tasks: nad Product Backlog Item zazwyczaj pracuje od trzech do pięciu osób – może jeden lub dwóch programistów, tester i ewentualnie designer, architekt, analityk lub technical writer itp. Przy Tasku pracuje zwykle tylko jedna osoba.

Oznacza to, że nie wszyscy członkowie zespołu muszą wspólnie szacować danego Taska, tak jak ma to miejsce w przypadku Product Backlog Item. Każdy w zespole może oczywiście zaproponować swoją ocenę, ale ostateczne szacowanie może przeprowadzić jedynie osoba, która ostatecznie będzie nad tym Taskiem pracować.

Jeśli z dużym prawdopodobieństwem tylko jedna konkretna osoba będzie pracować nad danym Taskiem, to właśnie jej szacunek należy przyjąć. Jeśli dwie lub trzy osoby będą pracować nad Taskiem, można albo poprosić je wszystkie o wspólne szacowanie, albo przyjąć ocenę osoby, która najprawdopodobniej wykona większość pracy.

Jeśli praca zostanie w trakcie Sprintu przekazana innej osobie, szacunki w najgorszym przypadku po prostu się zmienią. Jeśli szybszy członek zespołu przejmie pracę wolniejszego kolegi, zmieni szacunek z ośmiu na cztery punkty – lub odwrotnie.

Dlaczego nie używać Task Points?

Task Points nie mają więc żadnych zalet nad godzinami. Mają jednak wady w porównaniu ze Story Points:
- Wielu członków zespołu nie jest z nimi zaznajomionych.
- Konieczne jest ustalenie wartości bazowych, aby w ogóle można było dokonywać szacowań.
- Istnieje ryzyko, że z czasem szacowania przestaną nawiązywać do pierwotnych wartości bazowych.

Moja wskazówka dotycząca Task Points

Zakończyłem moje poszukiwania w świecie Task Points bez przekonania co do ich wartości. Nadal jestem zwolennikiem Sprint Planningu zorientowanego na zobowiązania, tak jak go znamy. Być może Sprint Planning zorientowany na pojemność to lepsza nazwa. Moim zdaniem ma on znaczące zalety w porównaniu ze Sprint Planningiem zorientowanym na velocity.

W przypadku większości zespołów Sprint Planning zorientowany na zobowiązania lub pojemność najlepiej sprawdza się z godzinami. Niektóre zespoły stosują ten proces, ale rezygnują z szacowania i korzystają z niego tylko podczas spotkań, aby ustalić, co można włączyć do Sprintu.

Inne zespoły w ogóle nie szacują Sprint Backlog Items. Każde z tych podejść może dobrze działać, gdy zespół zdobędzie już odpowiednie doświadczenie.

Cieszę się, że przeprowadziłem ten projekt, aby dowiedzieć się więcej o Task Points i zespołach, które ich używają.

Kiedy przyglądam się alternatywnym metodom szacowania, zawsze czuję pewien zawód, gdy nowe podejście nie okazuje się lepsze od istniejącego. Niestety zdarza się to dość często.

Mimo to znajdziemy ciągłe usprawnienia, do których dąży każdy agilista, jeśli będziemy rozważać jak najwięcej różnych opcji.

Tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony. 

Product Owner: zadania i wyzwania

=> Dowiedz się, czym zajmuje się Product Owner na co dzień.

Czym jest Scrum Story?

=> Tutaj dowiesz się, czym różnią się User Stories, Epiki i Tematy.