Jak długo powinno trwać spotkanie planowania sprintu?


16

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.


4
8 godzin na 10-dniowy sprint zdecydowanie dla mnie brzmi zbyt wiele. Dyskusje, które nie wymagają całego zespołu, powinny być prowadzone na osobne sesje, tylko dla zaangażowanych członków.
Péter Török,

1
Więc planujesz inne spotkania zamiast omawiać wszystko w planowaniu. Punkt odnotowany.
wleao

Powinny się odbywać dyskusje na temat nadchodzących pomysłów i planów, aby większość członków zespołu miała pewne podstawowe i wspólne zrozumienie na ich temat. Kryterium jest następujące: podczas spotkania planistycznego nikt nie powinien być zaskoczony, gdy usłyszy coś pewnego po raz pierwszy. Ilekroć zdarzy się taka „niespodzianka”, dostosuj ją, zwiększając ilość komunikacji, która ma miejsce przed następnym spotkaniem planistycznym. (Wyjątkiem są naprawdę przełomowe ogłoszenia pochodzące od właścicieli projektów).
rwong

Odpowiedzi:


31

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.


5
To prawdopodobnie dobry punkt wyjścia, ale należy również zauważyć, że musisz dostosować proces do swojego projektu, zespołu i organizacji, aby działał dla Ciebie. Tylko dlatego, że inni mieli szczęście, nie oznacza to, że będzie działać dla ciebie od razu po wyjęciu z pudełka.
Thomas Owens

6
Jeśli jednak zamierzasz wypróbować Scrum, prawdopodobnie powinieneś najpierw wypróbować go w oparciu o zdefiniowane wytyczne. Następnie, jeśli coś nie działa, popraw to. Jeśli zmienisz zasady, zanim jeszcze zaczniesz, pominiesz dowody empiryczne, które skłoniły ludzi, którzy opracowali Scrum, do rekomendowania tego, co zalecili - bez żadnych dowodów empirycznych, które wskazywałyby na to, że jest to dla ciebie niewłaściwe.
Matthew Flynn

@MatthewFlynn dobry punkt
HA

W moim trzyosobowym zespole przeważnie mieliśmy tylko półgodzinne sprinty, a gdy zespół miał 7 lat, przeważnie trwała to tylko godzina przez dwa tygodnie.
Zymus

27

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.


Godzina wydaje się nieco krótsza dla 3 programistów / 1 tydzień sprintu. Z drugiej strony właśnie ukończyłem stosunkowo niewielki projekt, w którym co 5 minut cotygodniowe planowanie sprintu. Zależy to od projektu i kart, ponieważ czasami potrzeba więcej (lub mniej) dyskusji podczas planowania sprintu.
konfigurator

2
Jedną z kluczowych idei Scruma, jako zwinnego frameworka, jest to, że <i> czasowe działania </i>, takie jak sprint, spotkanie planowania sprintu i codzienna stand-up / scrum. Chodzi o to, aby skupić się na rzeczy. Boks czasowy nie oznacza, że ​​nie możesz poświęcić mniej czasu niż wyznaczono. Tyle, że nie powinieneś brać więcej, ponieważ powoduje to, że ludzie tracą koncentrację, a także skraca czas, jaki zespół musi faktycznie wykonać.
Matthew Flynn

7

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.


1
Dlaczego nie rozpocząć procesu zgodnie z planem i stamtąd dostosować? Jeśli zdecydujesz się zastosować zwinne praktyki i nie ukształtowałeś swojej firmy w tym kierunku, już masz kłopoty.
JeffO,

3

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ę.


@GottliebNotschnabel: Dzięki, to nowe. Zamieniłem link na taki, który nie wymaga logowania.
Hugo,

2

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.


1

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ę.


-1

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.


Czy mógłbyś wyjaśnić tę opinię, ponieważ ja tylko kopiuję / wklejam akapit z Przewodnika Scrum?
Lenin
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.