Pomocne może być przeczytanie najpierw artykułów na temat Agile i Scrum Framework na tym blogu.
Jak planować spotkania sprintu?
Nikt nie lubi spotkań, które nie przynoszą rozsądnej wartości.
Ta powszechna prawda odnosi się do wszystkich spotkań, w tym tych zdefiniowanych we frameworku Scrum jako Zdarzenia Scrumowe (Planowanie Sprintu, Codzienny Scrum, Przegląd Sprintu, Retrospektywa Sprintu). Jeśli te wydarzenia nie przynoszą wystarczającej wartości, Scrum Master musi wkroczyć, aby pomóc wszystkim zdefiniować, co musimy zmienić, aby nie marnować czasu. Wydarzenia Scrumowe nie mają żadnej “wartości” same w sobie i muszą być odpowiednio przygotowane jak każde inne spotkanie.
>
Planowanie Sprintu & Przegląd Sprintu wyróżniają się jako najtrudniejsze Zdarzenia Scrumowe ze względu na zaangażowanie wielu grup interesu (deweloperzy, właściciel produktu, sponsorzy projektu i inni interesariusze). Kluczowe jest skupienie się podczas każdego z tych spotkań na wspólnych interesach i celach ważnych dla wszystkich tych grup interesów. W przeciwnym razie spotkania te mogą zmienić się albo w spektakl polowania na czarownice – “znajdźmy, kto jest wyłącznie odpowiedzialny za tę katastrofę!” (Przegląd Sprintu), albo w 3-godzinną dyskusję o najmniejszym szczególe niezbyt ważnego zadania (Planowanie Sprintu).
>
Dowiedz się, jak możemy zdefiniować te wspólne interesy
Przegląd nadruków
Skup się na celach, które ostatecznie przyniosą wartość ze spotkań.
Przegląd Sprintu’ma na celu “sprawdzenie wyniku Sprintu i określenie przyszłych dostosowań.” Co oznacza, że Przegląd Sprintu jest idealnym czasem na:
- Zespół scrumowy (Developerzy+Product Owner+Scrum Master) by pokazać co osiągnęli w zakresie uzyskania Celu Sprintu;
- Każdy obecny na Przeglądzie Sprintu, aby przekazać informacje zwrotne na temat tego, co właśnie widzieli lub testowali/używali ;
- Każdy obecny na przeglądzie sprintu, aby pomóc dostosować przyszłe plany rozwoju w celu lepszego dostosowania do bieżącego celu produktu lub dostosowania celu produktu.
.
.
Jak wyraźnie widzimy, każdy musi wnieść znaczący wkład w Przegląd Sprintu, aby stworzyć wzajemny, wspólny interes. Kuszące może być traktowanie Przeglądu Sprintu jako tylko “prezentacji deweloperskiej” (aka demo), ale w takim przypadku po co nam w ogóle spotkanie? Programiści powinni po prostu wysłać e-mail z prezentacją / podsumowaniem sprintu do wszystkich interesariuszy i czekać na osobne opinie. Co tutaj tracimy? Nie dajemy sobie możliwości doświadczenia sesji pracy zespołowej, więc nie ma miejsca na wspólne zainteresowanie.
Nie ma czegoś takiego jak “idealny scenariusz”, który będzie pasował do każdego przeglądu sprintu (każdy produkt jest inny i wymaga specyficznego podejścia), ale zawsze lepiej zacząć od czegoś niż od zera. Mam nadzieję, że kilka wskazówek, które przygotowałem poniżej, pomoże Ci wydobyć więcej wartości z Przeglądu Sprintu!
Wskazówki od Scrum Mastera:
– upewnij się, że będziesz częścią Przeglądu Sprintu (jako deweloper, właściciel produktu, scrum master lub jakikolwiek inny interesariusz) i wyjaśnij to innym członkom, którzy nie są do końca świadomi, jaki jest cel tego spotkania (punkty 1-3);
– jeśli masz jakieś tematy do omówienia, które nie są bezpośrednio związane z punktami 1-3, powinieneś zadać sobie pytanie, czy Przegląd Sprintu jest najlepszą okazją do omówienia tych tematów? (być może inne wydarzenie Scrumowe będzie bardziej odpowiednie dla tych tematów, które chcesz omówić lub po prostu musisz stworzyć osobne spotkanie);
>
– timebox każdego Przeglądu Sprintu! Zmusza to każdego uczestnika spotkania do skupienia się na rzeczach, które przynoszą największą wartość.
Na przykład 1h max:
- 15 min na prezentację/test na żywo rozwoju wykonanego w ostatnim sprincie ;
- 15 min na zebranie informacji zwrotnej na temat rozwoju wykonanego w ostatnim sprincie ;
- 30 min dyskusja i praca nad możliwymi korektami Celu Produktu & zmiana kolejności/tworzenie Backlogu Produktu Pozycje;
– Zespół Scrumowy powinien być wystarczająco przygotowany, aby poprosić nietechnicznego członka Przeglądu Sprintu o zademonstrowanie nowych funkcji/funkcjonalności na żywo podczas spotkania;
– nie ma nic złego w przygotowaniu wstępnie skonstruowanej agendy na Przegląd Sprintu.
(tylko uważaj, aby nie skopiować/wkleić Backlogu Produktu do agendy & pamiętaj, aby zostawić odpowiednią ilość czasu na dyskusję/wprowadzenie poprawek! )
– zanotuj informacje zwrotne i wszelkie inne cenne punkty dyskusji! (mogą one być świetną podstawą do Retrospektywy Sprintu);
>
Planowanie Sprintu
Celem Planowania Sprintu jest zaplanowanie pracy do wykonania w celu osiągnięcia Celu Sprintu. Plan ten powinien być wynikiem wspólnej sesji roboczej całego Zespołu Scrumowego (i wszelkich innych gości poproszonych o wzięcie w niej udziału, jeśli istnieje taka potrzeba).
Aby wydobyć największą wartość z Planowania Sprintu musimy zadać sobie i zdefiniować odpowiedzi na te 3 pytania.
A) Dlaczego ten Sprint jest wartościowy?
>
Właściciel Produktu musi być przygotowany do rozpoczęcia dyskusji na temat kierunku, w którym produkt powinien być rozwijany podczas następnego sprintu. Jasno zdefiniowany Cel sprintu powinien być wynikiem tej dyskusji.
B) Co można zrobić w tym sprincie?
>
Deweloperzy mogą teraz zaproponować i omówić, które elementy zaległości wprowadzą do Rejestru Sprintu, aby osiągnąć Cel Sprintu.
C) Jak wybrana praca zostanie wykonana?
>
Określenie, w jaki sposób elementy pracy zostaną przekształcone w wartościowe rozwiązania, leży wyłącznie w gestii Deweloperów (są oni odpowiedzialni za Backlog Sprintu).
Planowanie Sprintu wymaga uwagi i przygotowania od wszystkich w nie zaangażowanych. Wspólny interes pojawi się tylko przy wzajemnym zrozumieniu szerszego kontekstu planowania pracy (Dlaczego – Co – Jak). Musimy stale sobie o tym przypominać, aby wnieść jak najwięcej wartości z wydarzenia Planowania Sprintu. W przeciwnym razie spotkanie to zdegeneruje się do po prostu “przesuwania” zadań między Product & Sprint Backlog, co jest oczywistą stratą czasu.
>
Zapoznaj się z kilkoma wskazówkami, które przygotowałem dla Ciebie, aby przygotować się do świetnej sesji Planowania Sprintu
Wskazówki od Scrum Mastera:
– upewnij się, że będziesz częścią Planowania Sprintu (jako deweloper, właściciel produktu, scrum master lub jakikolwiek inny interesariusz) i wyjaśnij to innym członkom, którzy nie są do końca świadomi, jaki jest cel tego spotkania (punkty A-B-C);
– jeśli masz jakieś tematy do omówienia, które nie są bezpośrednio związane z punktami A-B-C, powinieneś zadać sobie pytanie, czy Planowanie Sprintu jest najlepszą okazją do omówienia tych tematów? (być może inne Wydarzenie Scrumowe będzie bardziej odpowiednie dla tych tematów, o których chcesz porozmawiać lub po prostu musisz stworzyć osobne spotkanie);
>
– timebox każdego Planowania Sprintu!
Popycha to każdego członka spotkania do skupienia się na rzeczach, które przynoszą największą wartość. Na przykład 90 min max:
- 15 min na prezentację kolejnych pomysłów rozwojowych, które są potrzebne do osiągnięcia Celu Produktu (Właściciel Produktu)
- 15 min na dyskusję o danym pomyśle rozwojowym w celu określenia Celu Sprintu (Zespół Scrumowy) ;
- 30 min na optymalizację Backlogu Sprintu poprzez wybór pozycji Backlogu Produktu, które muszą zostać opracowane w celu uzyskania Celu Sprintu (Zespół Scrumowy);
- 30 min na dyskusję o tym, jak przekształcić pozycje Backlogu Sprintu w wartościowe rozwiązanie, które zrealizuje Cel Sprintu. (Deweloperzy)
– niezwykle ważne jest zapewnienie wystarczającej ilości czasu na właściwe omówienie i dopracowanie elementów pracy, które zostaną przypisane do Rejestru Sprintu. Skupienie się na zdefiniowanym Celu Sprintu pozwoli zauważyć i omówić wszelkie możliwe problemy/blokady jeszcze przed rozpoczęciem rozwoju!
>
– zadaj sobie pytanie, czy Twój Cel Produktu jest realny? (zdecydowanie powinien istnieć!) Właściciel Produktu nie powinien mieć problemu z opisaniem, jakie są niezbędne kolejne kroki potrzebne do osiągnięcia tego celu. Ten opis będzie doskonałym miejscem do rozpoczęcia dyskusji na temat następnego Celu Sprintu.
>
– czasami korzystne będzie podzielenie sesji Planowania Sprintu na dwie części A)+B) / C), aby wyeliminować pewne niedogodności. Na przykład, jeśli deweloperzy znajdują się w innej strefie czasowej niż reszta Zespołu Scrumowego, być może powinni być w stanie przygotować plan rozwoju (punkt C) oddzielnie dzień po Planowaniu Sprintu (A+B) i udostępnić go Zespołowi Scrumowemu w Backlogu Sprintu.
>
(tylko uważaj, aby nie skopiować/wkleić Backlogu Produktu do agendy& pamiętaj, aby zostawić odpowiednią ilość czasu na dyskusję/wprowadzenie poprawek! )
– zanotuj informacje zwrotne i wszelkie inne cenne punkty dyskusji! (mogą one być świetną podstawą do Retrospektywy Sprintu);
>
