Właściwy moment na Planning Poker
Planning Poker to metoda szacowania oparta na konsensusie. Dlatego polecam używać jej do elementów, które wymagają konsensusu – czyli raczej do Product Backlog Items niż do zadań w Sprint Backlogu. W tym artykule wracam do tematu Planning Poker i wyjaśniam, kiedy najlepiej go przeprowadzać.
Powody szacowania User Stories
Szacowanie User Stories w Product Backlogu ma dwa powody:
1.) Product Backlog może zostać spriorytetyzowany. Wyobraź sobie dwa Product Backlog Items, które Product Owner uważa za równoważne. Element o niższym koszcie zostanie wtedy zrealizowany jako pierwszy. Oceny elementów zależą więc od ich kosztów i mogą być wykorzystywane do priorytetyzacji.
2.) Firma może tworzyć długoterminowe prognozy. Zakres pracy musi być znany, aby Product Owner mógł określić, kiedy i ile można dostarczyć.
Kiedy grać w Planning Poker?
Korzystając z powyższych punktów, można ustalić, kiedy zespół powinien przeprowadzać szacowania. Z jednej strony powinno to nastąpić wystarczająco wcześnie, aby spełnić oba warunki. Z drugiej strony – nie wcześniej niż jest to absolutnie konieczne.
W praktyce istnieją dwie sytuacje, w których zespół powinien grać w Planning Poker.
Dobrym momentem na Planning Poker jest na przykład czas po warsztatach Story Writing Workshop, podczas których powstało wiele Product Backlog Items. Takie warsztaty powinny odbywać się mniej więcej raz na kwartał.
Dzięki temu Product Owner i zespół mogą wyznaczyć większy cel (niemożliwy do osiągnięcia w jednym Sprincie) i stworzyć potrzebne do niego User Stories.
Typowo podczas kwartalnego Story Writing Workshop powstaje od 20 do 50 Product Backlog Items. Jeśli można oszacować około 20 elementów na godzinę, szacowanie zajmie łącznie około dwóch godzin na kwartał.
Ponadto Planning Poker można przeprowadzać raz na Sprint. Niektóre zespoły robią to podczas regularnego spotkania Product Backlog Grooming. To jest całkowicie w porządku – o ile wszyscy członkowie zespołu biorą w nim udział.
Jeśli nie wszyscy członkowie zespołu są zaangażowani, Planning Poker można przeprowadzić po Daily Standup pod koniec Sprintu. Jeśli zespół przeprowadza szacowania zbyt wcześnie w trakcie Sprintu, może być konieczne powtórzenie całego procesu dla Stories dodanych później.
Nie należy jednak też szacować zbyt późno. W takim przypadku Product Owner nie będzie mógł uwzględnić tych elementów przy ustalaniu zakresu następnego Sprintu.
Kiedy nie grać w Planning Poker?
Jest jeden moment, który jest nieodpowiedni dla Planning Poker: początek Sprint Planning Meeting. Jest to wtedy zbyt późno, aby Product Owner mógł uwzględnić nowe szacowania przy ustalaniu priorytetów.
Może zdarzyć się, że niektórzy Product Ownerzy są w stanie błyskawicznie przeorganizować priorytety. Jednak więcej czasu zawsze jest lepsze.
Kolejnym problemem jest to, że zespół prawie zawsze spędza zbyt dużo czasu na szacowaniu, gdy Sprint Planning zaczyna się od Planning Poker. Myślę, że wynika to z tego, że członkowie zespołu zaczynają od razu zagłębiać się w szczegóły swoich User Stories.
Podczas Planning Poker powinni natomiast podawać mniej szczegółowe szacunki. Trudno jest w jednym spotkaniu podawać tak przybliżone oceny, gdy jednocześnie trzeba znacznie dokładniej wyceniać Tasks.
Prowadzi to do niepotrzebnie długich dyskusji. A to z kolei sprawia, że zespół potrzebuje znacznie więcej czasu, niż gdyby przeprowadzał obie rzeczy osobno.
Korzystając z tych wskazówek, powinieneś być w stanie znaleźć właściwy moment na Planning Poker.
Tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony.
