wtorek, 20 sierpnia 2013

Praktyczne wskazówki jak należy przeprowadzać spotkania produkt backlog grooming/backlog refinement

Sesja product backlog grooming

Dla tych którzy jeszcze nie spotkali się z tym terminem zacznę od krótkiego wyjaśnienia, dłuższy opis po kliknięciu na link: backlog grooming. W scrum oznacza dbanie o aktualność i spójność itemów w produkt backlog czyli krócej chodzi o wysoką jakość product backlogu. Realizacja odbywa się poprzez spotkanie produkt ownera z zespołem podczas którego omawiane są wszystkie user stories na najbliższą iterację, ewentualnie uzupełniane o nowe use casy, rozbijane na mniejsze jeśli potrzeba czy w końcu estymowane zespołowo(np. poprzez sesję planning poker).

Poniżej przedstawiam listę praktycznych sugestii które z pewnością pomogą każdemu zespołowi sprawniej przebrnąć przez spotkanie, zaoszczędzić trochę czasu, może zdrowia :) i wypracować z czasem w Waszych zespołach dobre zwyczaje. Załóżmy długość trwania sprintu jako 4 tygodnie. Jeśli chodzi o czas trwania spotkania, zazwyczaj zespoły zużywają ok. 5-8% czasu sprintu na grooming backlogu(dla sprintu trwającego 20 dni jest to ok. 1-1,5 dnia )

1. Kiedy należy przeprowadzić spotkanie? Mając 4 tygodniowy sprint, każdy tydzień odpowiada za 25% prac, chcąc umiejscowić spotkanie backlog grooming precyzujące zakres nowego sprintu musimy mieć na uwadze 2 rzeczy. Napewno nie chcemy zaprzątać zespołowi głowy podczas pierwszego tygodnia prac, kiedy to wystartowali z developmentem nowych funkcjonalności, zespół wówczas musi dobrze wejść w obecny sprint. To samo dotyczy ostatniego tygodnia kiedy to zespół stara się dowieźć 100 % zakresu na który się zgodził. Środkowe 2 tygodnie są odpowiednim momentem na zaplanowane spotkania backlog grooming na kolejny sprint. 

2. Staraj się traktować spotkanie backlog grooming jako pierwszą część spotkania sprint planning. Jak wiemy spotkanie sprint planning dzieli się na dwa kawałki, pierwszy podczas którego omawiamy funkcjonalności które chcemy zrobić oraz drugi kiedy to dzielimy itemy na zadania. Podczas pierwszej części produkt ower prezentuje itemy, zespół zadaje pytania, kiedy wszystko jest jasne itemy są wspólnie estymowane. Produkt owner w oparciu o wypracowane wspólnie estymacje może zmienić priorytety, o to chodzi.

3. Znając dostępność zespołu i jego velocity jako produkt owner staraj się przygotować ok. 25% więcej itemów niż zostanie zrobione podczas najbliższego sprintu. Powody są choćby dwa, mając więcej jesteś pewien że jeśli ktokolwiek z zespołu zwolni się szybciej masz gotowy item do wzięcia, dodatkowo w oparciu o feedback zespołu często itemy będą zmieniały swój pierwotny priorytet, więc należy mieć więcej aby spokojnie wypełnić zakres przyszłego sprintu.

4. Jako produkt owner pamiętaj aby zespół wiedział iż estymacje i priorytety nadawane podczas spotkania mogą się jeszcze zmieniać. Zmiana może zajść do momentu kiedy dany item nie zostanie zaakceptowany i nie trafi na sprint planning. Zanim to nastąpi zespół może uzupełniać item o nowe use casy, informacje które wcześniej nie były znane. W kontekście priorytetów scrum zawsze wychodzi na przeciw i jest elastyczny wobec zmiany priorytetów podyktowanych przez biznes. Z praktyki jednak wynika że pomiędzy spotkaniem backlog grooming a sprint planning rozpoczynającym prace developerskie zmianom priorytetu ulega max ok. 5-8% zakresu. Rzadkością są duże zmiany które zmieniają mocno zakres. 

5. Miło jeśli zespół zrobi przegląd odpowiednich itemów dzień przed spotkaniem. Odpowiedzialnością produkt ownera jest przegląd i doprecyzowanie produkt backlogu tak aby zespół developerski w oparciu o dane tam zawarte zbudował nowe funkcjonalności. Dopuszcza się również praktykę spotkania z jednym z członków zespołu (dziedzinowym SME- Subject Matter Expert) i przygotowanie itema/ów o oparciu o jego wiedzę. Również produkt owner obowiązany jest do posiadania pełnej wiedzy na temat wszystkich itemów. 

6. To jest właściwy czas aby podzielić duże itemy na mniejsze. Jeśli ktokolwiek z zespołu uzna że warto podzielić item i przedstawi ku temu rozsądne argumenty wówczas należy item podzielić i estymować oba ponowie.

7. Optymalizuj i monitoruj czas spotkania. Jeśli natrafisz na itemy które były bazą poprzedniego spotkania, szybko zrób przegląd i estymuj ponownie tylko jeśli od poprzedniego spotkania do teraz ktokolwiek dodał jakąś nową informację. Wówczas przedyskutuj w ramach zespołu nową aktualizację i przystąp do estymacji jeśli item się nie zmienił sam zdecyduj czy warto go przypomnieć czy jest znany zespołowi.

8. Czasem warto na spotkaniu przejrzeć kilka itemów z końca product backlog. Powodów jest kilka ale dwa najważniejsze to: produkt owner musi znać zgrubny rozmiar takiego itema oraz zespół deweloperski powinien zidentyfikować zewnętrzne lub wewnętrzne zależności które muszą być rozwiązanie zanim będzie można przystąpić do dokładnej analizy.

9. Jako Produkt Owner nie obawiaj się prezentować itemów które późno wchodzą do zakresu prac. Powodem robienia spotkania jest odkrycie nieznanego i zidentyfikowanie ryzyk lecz nie wszystko da się przewidzieć. Należy pro aktywnie przyjąć i estymować taki item/y, natomiast jeżeli zdarza nam się to przy okazji każdej iteracji wówczas należy poszukać przyczyny i zacząć minimalizować wpływ.

10. Uczestnikami spotkania powinien być cały zespół scrumowy. Są przypadki iż może się okazać potrzebna dodatkowo osoba np. z biznesu lub innego działu firmy. W takim momencie ogranicz uczestnictwo takiej osoby do itemów co do których ma coś do powiedzenia.

11. Nie zapominaj o robieniu sprint retrospektywy. Jeżeli zespół uzna tą praktykę za stratę czasu wówczas z pewnością mamy przeszkodę do usunięcia. Wykonaj analizę "Five Why's" i na tej podstawie dokonaj zmian, ulepszeń, uzgodnień zespołem.

Konkluzją tego posta powinna być i będzie stwierdzenie: "Dobrze zrobione spotkanie backlog grooming powinno zrealizować nam pierwszą część spotkania sprint planning". Jeśli jesteśmy na tyle dojrzałym zespołem przechodzimy wtedy od razu do dzielenia itemów na zadania (części drugiej spotkania sprint planning czyli jak coś zrobić). Będąc nawet małym zespołem powinniśmy czerpać korzyści ze spotkania, korzyści płynące to wzrost wiedzy na temat budowanych funkcjonalności i całego produktu oraz wzrost produktywności zespołu.

Zapraszam do dzielenia się Waszymi spostrzeżeniami w komentarzach.

1 komentarz:

  1. Bardzo cenne porady, ciężko się nie zgodzić. Polecam tez zajrzeć do mojego wpisu o podobnej tematyce. Większość wskazówek się powtarza, ale jest też kilka, których nie uwzględniono w tym wpisie. Zamieszczam link poniżej.

    http://jestempm.pl/scrum-backlog-grooming

    OdpowiedzUsuń