Jak długo powinno trwać spotkanie planowania sprintu?

Z doświadczenia wynika, jak długo powinno trwać spotkanie planowania sprintu (Scrum)? 8 godzin? A może powinien być krótszy (zwięzły), a dalsze rozmowy powinny być zaplanowane w ramach sprintu? Nasze sprinty trwają 10 dni.

Według Przewodnika Scrum :

Spotkanie planowania Sprintu jest ograniczone do ośmiu godzin na miesięczny Sprint. W przypadku krótszych sprintów wydarzenie jest proporcjonalnie krótsze. Na przykład dwutygodniowe Sprinty mają czterogodzinne spotkania planowania sprintu.

To na ogół działa dla mnie.

Tak długo, jak to musi trwać, nie mniej i nie więcej. Cokolwiek innego nie jest zwinne.

Jeśli masz zespół 2-3 programistów i wykonujesz 1-tygodniowe sprinty, cokolwiek więcej niż godzina jest prawdopodobnie nieproduktywne.

Jeśli masz zespół 15 osób i 2-tygodniowe sprinty, na które patrzysz przez cały dzień, nic mniej nie jest wystarczająco szczegółowe.

Potrzeba doświadczenia, aby właściwie to zrobić, i na tym właśnie polegają retrospekcje, zespół decyduje, co jest za długie lub za krótkie.

Nie martw się, że uda Ci się go perfekcyjnie dopasować lub trzymać się tego, co mówi jedna z książek, spróbuj czegoś i dopracuj.

SCRUM polega na dopracowaniu procesu w iteracjach, tak samo jak na dopracowaniu kodu w iteracjach.

Nie kształtuj swojej firmy w trakcie całego procesu. Proces wspiera Twoją firmę. W momencie, gdy robisz proces dla samego siebie, nadszedł czas, aby proces zdobył topór. W tym celu nie ma „właściwej” drogi. Spotkania powinny trwać tylko tak długo, jak długo coś w nich osiągasz. Jeśli zajmie ci to 30 minut lub 4 godziny, o ile działa, to idź z tym. Zignoruj ​​to, co mówi Ci książka / blog / trener, i rób to, co jest dla Ciebie odpowiednie.

Poświęć tyle czasu, ile potrzebujesz, aby wybrać wystarczająco dużo, aby zespół uznał, że można go osiągnąć w sprincie. Ale powinieneś spędzać czas podczas (poprzedniego) sprintu, dopracowując zaległości: szacując i doskonaląc historie.

Z Scrum Primer ( PDF ):

Udoskonalenie rejestru produktów

Jedną z mniej znanych, ale cennych wskazówek w Scrumie jest to, że pięć lub dziesięć procent każdego Sprint musi być poświęcone przez Zespół na dopracowanie (lub „uwodzenie”) Backlogu Produktu. Obejmuje to szczegółową analizę wymagań, podział dużych elementów na mniejsze, oszacowanie nowych pozycji i ponowne oszacowanie istniejących pozycji. Scrum milczy na temat tego, jak ta praca jest wykonywana, ale często stosowaną techniką są skoncentrowane warsztaty pod koniec Sprintu, aby zespół i właściciel produktu mogli poświęcić się tej pracy bez przerwy. W przypadku dwutygodniowego sprintu pięć procent czasu trwania oznacza, że ​​w każdym sprincie trwają półdniowe warsztaty doskonalenia rejestru produktów. To udoskonalenie nie dotyczy przedmiotów wybranych do bieżącego Sprintu; dotyczy przedmiotów na przyszłość, najprawdopodobniej w ciągu jednego lub dwóch Sprintu. Dzięki tej praktyce planowanie sprintu staje się stosunkowo proste, ponieważ właściciel produktu i zespół Scrum rozpoczynają planowanie od jasnego, dobrze przeanalizowanego i starannie oszacowanego zestawu elementów. Znakiem, że te warsztaty doskonalenia nie są przeprowadzane (lub nie są robione dobrze) jest to, że Planowanie Sprintu wiąże się z poważnymi pytaniami, odkryciami lub zamieszaniem i wydaje się niekompletne; prace planistyczne często przenoszą się na sam Sprint, co zwykle nie jest pożądane.

Dzięki temu możesz skupić się na planowaniu podczas planowania i nie zajmuje to całego dnia, a zespół zaczyna tracić koncentrację i nudzić się.

W Scrumie, gdy pracujesz nad 2-tygodniowymi sprintami, planowanie sprintu jest ograniczone czasowo do 4 godzin, co czyni go wydarzeniem pół dnia. Jednym z powodów stosunkowo dużej ilości czasu jest to, że zespół programistów musi mieć pewność, że wszystkie elementy wciągnięte do zaległości sprintu mogą zostać dostarczone, co oznacza, że ​​muszą znać szczegóły. Często zdarza się, że w ramach planowania sprintu zespoły odrywają się od przestrzeni spotkań na pewien czas, aby dalej badać przedmioty i upewnić się, że są „gotowe” do przejścia do zaległości sprintu. (Pomóc może myśleć o planowaniu sprintu jako o wydarzeniu, a nie o spotkaniu).

Skorzystaj z „Definicji gotowości” i czasu, w jakim wydarzenie planowania sprintu pozwala upewnić się, że wszystkie zaległe elementy wchodzące do sprintu są zarówno wykonalne, jak i gotowe . tzn. można je wykonać (całkowicie zgodnie z „Definicją ukończenia”) w trakcie sprintu, a zespół ma wystarczającą ilość informacji, aby mógł je teraz wykonać.
Pamiętaj oczywiście, że prawdopodobnie nie chcesz tego robić dla WSZYSTKICH przedmiotów podczas planowania sprintu, ponieważ może to być bardzo czasochłonne. Staraj się regularnie dbać o zaległości (bez planowania sprintu), w których możesz rozbić zaległości i oszacować przedmioty, których jeszcze nie oszacowano, na przykład przy planowaniu pokera. (Przekonałem się, że może to być skuteczne zajęcie podczas pracującej kolacji z zespołem programistów, jeśli masz luksus dostępności swojego zespołu podczas kolacji!)

Przedmioty o wysokim priorytecie mogą być często dodawane do rejestru produktu przez właściciela produktu tuż przed planowaniem sprintu, a podczas gdy rutynowe czyszczenie zaległości może i zwykle powinno być wykonane przed wydarzeniem planowania sprintu, zawsze będą takie nowe elementy, gdzie zespół musi poświęcić czas na wypracowanie szczegółów i oszacowanie złożoności podczas planowania sprintu, dlatego też może on rozciągać się do 4 godzin na 10-dniowy / 2-tygodniowy sprint.

Jeśli musisz wziąć dłuższe dyskusje z tego wydarzenia, możesz mieć element zaległości w dzienniku sprintu, aby „przeprowadzić taką i taką dyskusję w celu ustalenia x”, ale powinieneś unikać dodawania elementów sprintu, aby zrobić wszystko, co zamierzasz określić potrzeby wykonane podczas tej dyskusji, ponieważ nie są to „gotowe” elementy zaległości do przejścia do sprintu.

Jak powiedzieli ludzie, istnieją powody, dla których możesz chcieć zmienić sposób działania Scruma, jeśli proces nie działa dla ciebie skutecznie. Scrum jest jednak bardzo dobrze przemyślaną i przetestowaną platformą na początek, dlatego upewnię się, że twoje rozumowanie jest uzasadnione przed zmianą procesu.

Na spotkaniu dotyczącym planowania sprintu zespół musi ustalić dwa zestawy rzeczy:

A) Co zostanie opracowane przez zespół podczas tego sprintu

B) Jak to będzie rozwijane

Spotkanie musi być ograniczone czasowo, do dwóch godzin na każdy tydzień Sprintu, podzielone równomiernie na każdą część (część A i część B) spotkania.

Tak więc przez 4 tygodnie sprintu spotkanie nie powinno trwać dłużej niż 8 godzin, do 4 godzin dla części A i do 4 godzin dla części B.

Podczas części A zespół deweloperów musi oszacować prędkość zespołu, którą według nich będzie miał podczas tego sprintu. Muszą także oszacować historie użytkowników o najwyższym priorytecie i wybrać wystarczającą liczbę (już oszacowanych) historii użytkowników, aby ukończyć je zgodnie z własną oszacowaną prędkością zespołu.

W części B zespół deweloperów omówi sposoby tworzenia trudniejszych historii użytkowników, które zostały już wybrane do opracowania. Najprawdopodobniej zespół deweloperów nie będzie miał wystarczająco dużo czasu na omówienie, jak opracować wszystkie wybrane historie użytkowników, więc zespół musi wybrać najbardziej wymagające historie użytkowników.

Podczas sprintu zespół programistów ma wystarczająco dużo czasu, aby ukończyć tę dyskusję.

Według Przewodnika Scrum :

Wydarzenia Scrumowe

Zdefiniowane zdarzenia są używane w Scrumie, aby zapewnić regularność i zminimalizować potrzebę spotkań nieokreślonych w Scrumie. Wszystkie zdarzenia są zdarzeniami z przedziałem czasowym, tak że każde zdarzenie ma maksymalny czas trwania. Po rozpoczęciu sprintu czas jego trwania jest ustalony i nie można go skracać ani przedłużać. Pozostałe zdarzenia mogą się kończyć za każdym razem, gdy cel zdarzenia zostanie osiągnięty, zapewniając odpowiednią ilość czasu, nie dopuszczając do marnotrawstwa w procesie.