Planning poker: strategia „all-in” w szacowaniu w Agile

Wyobraź sobie, że kupiłeś dom i planujesz przebudowę kuchni. Pytasz wykonawcę, jak długo potrwa remont i ile będzie kosztował. Otrzymujesz szacunkowy koszt, ale dwa miesiące później żałujesz swojej decyzji, ponieważ projekt znacznie przekracza pierwotny harmonogram i budżet. 

Kiedy masz opinię tylko jednej osoby, możesz liczyć się tylko z jej wkładem i wiedzą. Jednak gdy do rozmowy włączysz więcej osób o różnym doświadczeniu, uzyskasz bardziej wszechstronne i dokładne oszacowanie pracy, którą należy wykonać.

To oparte na konsensusie szacowanie stanowi podstawę metody Agile planning poker. 

Czym jest planning poker?

Planning poker to metoda szacowania, która pomaga zespołowi Agile oszacować nakład pracy potrzebny do ukończenia jednej historii użytkownika w backlogu produktu. Często używana w zwinnych metodologiach zarządzania projektami, jest czasami określana jako „poker Scrumowy” lub „poker punktowy”. Słowo „poker” w nazwie odnosi się do kart, których każdy członek zespołu używa podczas tego procesu.

Historia planning pokera

Planning poker opiera się na technice znanej jako Wideband Delphi. Wideband Delphi to oparty na konsensusie proces szacowania opracowany w połowie XX wieku przez RAND Corporation, think tank non-profit. 

James Grenning, autor „Manifestu zwinnego tworzenia oprogramowania”, udoskonalił technikę Wideband Delphi w 2002 roku i zmienił jej nazwę na Planning Poker. Została ona następnie udoskonalona i spopularyzowana przez Mike'a Cohna w jego książce „Agile Estimating and Planning” z 2005 roku. 

Jak działa planning poker

Proces planning poker odbywa się na wczesnym etapie planowania sprintu, dzięki czemu Scrum Master i menedżerowie produktu mogą dokładnie ocenić, ile pracy można ukończone w każdym sprincie. Oto jak to działa:

1. Utwórz karty do planning pokera

Każdy członek zespołu Scrum lub Agile ma prezentację kart o różnych wartościach. Każda karta będzie miała jedną z tych wartości: 0, 1, 2, 3, 5, 8, 13, 20, 40 i 100. Liczby te mogą wydawać się losowe, ale w rzeczywistości są zaokrąglonymi wariantami ciągu Fibonacciego. Wartości te najczęściej reprezentują punkty historyjek. Jednak niektóre zespoły mogą używać ich jako szacunków czasowych określających, ile czasu może zająć ukończenie historii użytkownika. Najczęściej szacunki czasowe są mierzone w godzinach.

Właściciel produktu lub Scrum Master będzie pełnił rolę moderatora i przeczyta konkretną historię użytkownika z backlogu produktu lub sprintu. Następnie członkowie zespołu mają możliwość zadawania pytań i wyjaśniania wątpliwości, aby cały zespół mógł uzyskać dokładne wyobrażenie o tym, jakie zadania należy wykonać w odniesieniu do tego konkretnego elementu backlogu. 

Oto kilka pytań, które zespół może zadać, aby lepiej zrozumieć historię użytkownika:

• Jakie techniki możemy wykorzystać, aby ukończone zostały zadania z tej historii?

• Ile osób będzie musiało pracować nad tą historią?

• Jak zareagują interesariusze, jeśli wystąpią jakiekolwiek opóźnienia w tej historii?

2. Zagłosuj na każdą historię użytkownika

Gdy zespół zakończy dyskusję na temat jednej historii użytkownika, każda osoba dokonująca szacowania wybiera kartę odpowiadającą nakładowi pracy lub punktom historyjek, które jej zdaniem odpowiadają temu elementowi backlogu. Następnie wszyscy pokazują swoje karty w tym samym czasie. Jeśli wszyscy wybiorą tę samą wartość szacunkową, staje się ona oficjalnym szacunkiem dla tego elementu backlogu. Celem jest, aby wszyscy mieli takie samo oszacowanie. 

3. Osiągnij konsensus

Jeśli członkowie zespołu mają różne opinie na temat swoich początkowych szacunków, członek zespołu z najwyższą oceną i członek zespołu z najniższą oceną poświęcają trochę czasu na omówienie, dlaczego wybrali tę konkretną liczbę. Po zakończeniu dyskusji wszyscy ponownie wybierają swoje karty. Proces ten powtarza się, aż zespół osiągnie konsensus. 

4. Zaplanuj sprint

Teraz, gdy wszystkie elementy w backlogu mają przypisane szacunki, znacznie łatwiej jest dokładnie zaplanować sprint. Ponieważ cały zespół osiągnął konsensus co do tego, ile czasu zajmie każde zadanie, znacznie bardziej prawdopodobne jest, że będziesz w stanie dopasować odpowiednią ilość pracy do swoich sprintów.

Kiedy zorganizować sesję planning pokera

Planning poker zwykle odbywa się tuż przed procesem planowania sprintu, więc menedżer produktu lub Scrum Master może uzyskać dokładne wyobrażenie o pracy przed zaplanowaniem sprintu. Możesz użyć tej metody szacowania raz na sprint. Ponieważ elementy są stale dodawane do backlogu produktu lub sprintu, powinieneś mieć stałą podaż elementów backlogu do wykorzystania w każdym sprincie. 

Jeśli masz tylko niewielką liczbę historii użytkowników do omówienia w backlogu produktu, możesz połączyć tę sesję z końcem codziennego spotkania stand-up, ponieważ wszyscy członkowie zespołu są już obecni. 

Zalety planning pokera

Główną zaletą planning pokera jest to, że szacunki zespołu są dokładniejsze. Dokładne oszacowanie jest ważną częścią procesu planowania sprintu, ponieważ daje zarówno zespołowi, jak i interesariuszom realistyczny harmonogram, w którym zadanie zostanie ukończone.

Oto kilka innych sposobów, w jakie planning poker może przynieść korzyści zespołowi Agile:

• Każdy członek zespołu ma coś do powiedzenia. Każdy członek zespołu programistycznego jest ważny, a ten proces daje mu możliwość wyrażenia swojego zdania. Może to pomóc członkom zespołu w większym zaangażowaniu w pracę. 

• Członkowie zespołu mają możliwość omawiania historii użytkładających się na całość. Podczas procesu planning poker zespół programistyczny ma możliwość wspólnej dyskusji na temat historii użytkowników przed rozpoczęciem jakiejkolwiek pracy. Dzięki temu wszyscy mają takie samo zrozumienie tego, jak należy rozwiązać konkretne historie użytkownika, niezależnie od tego, który programista został do niej przypisany. 

• Szacunki dotyczące zadań są względne w stosunku do innych zadań. Kiedy Twój zespół używa punktów historyjek do przedstawienia liczby na karcie do pokera planistycznego, łatwiej jest zrozumieć, ile nakładu pracy będzie wymagało konkretne zadanie w porównaniu z innymi zadaniami w projekcie. Na przykład historia użytkownika z szacunkową wartością 2 będzie znacznie łatwiejsza do ukończone niż historia użytkownika z szacunkową wartością 40.

Zaplanuj swój sprint za pomocą narzędzia do zarządzania pracą

Utrzymuj swój zespół Agile na bieżąco, korzystając z narzędzia do zarządzania pracą. Asana pomaga planować i organizować projekty Agile w narzędziu, które jest elastyczne i oparte na współpracy. Niezależnie od tego, czy Twój zespół pracuje na tablicy Kanban, czy na bardziej liniowej osi czasu, Asana oferuje funkcje, które pomogą Twojemu zespołowi Agile szybko tworzyć produkty.