Planowanie sprintu

Artykuł
06/10/2015

Przez Mitch Lacey.Właściciel, Mitch Lacey & stowarzyszonych, Inc konsultacje bezpośrednie potwierdzone zajmujących elastyczne i scrum przyjęciach i usprawnienia.

Styczeń 2012.

Planowanie sprintu musi być trudne.Często jest możliwości i godzinę cały Scrum zespołu do tworzenia camaraderie przez pracy zebranie w odpowiedzi na pytanie "Co możemy przekazać do?" W tym artykule autorzy podają przykłady i strategie konkretnego planowania sprintu i efektywnego i szczegółowo opisują potencjalne rozwiązania typowych problemów zespoły napotykanych podczas planowania sprintu.

Dotyczy

Zarządzanie cyklem życia aplikacji; Team Foundation Server

W tym artykule:

Wprowadzenie
Funkcja prognozowania i zatwierdzania
Co to jest planowanie Sprintu?
Jak możemy ją zrobić?
Typowych problemów
- Scenariusz: Zespołu nie można przekazać do wszystkich wątków, który zgłosił żądanie właścicielem produktu.
- Scenariusz: Właścicielem produktu nie pochodzi przygotowane.
- Scenariusz: Część 1 przekracza jego timebox.
- Scenariusz: Część 2 przekracza jego timebox.
- Scenariusz: Właścicielem produktu nie jest dostępny.
- Scenariusz: Zespół nie ma wymaganych kryteriów akceptacji.
- Scenariusz: Właścicielem produktu nie może ustalić oznacza co zrobić.
- Scenariusz: Właściciela ScrumMaster lub produktu jest szacowanie/wpływające na pracy szacuje zespołu.

Nie planujemy.Firma Microsoft Scrum, dlatego firma Microsoft wykonać.

Mogę Posłuchaj, co to cały czas.Myślenia tego Scrum i elastyczne nr średniej planowania, nie szacowanie, brak spotkań nie wszystko!Nie może być dalej od PRAWDA.Planujemy na różnych poziomach w projekcie elastyczne: dzienny plan lub codziennie spotkania aktualizacyjne, co tydzień plany (zaległości sprint lub iteracji,), plan release (zaległości produktu) i potencjalnie itp.

Przyjrzyjmy skupić się na planowania sprintu.

Funkcja prognozowania i zatwierdzania

W lata 2011 r., zaktualizowany Ken Schwaber i Jan Sutherland ich przewodnik Scrum.W nim usuwane co zachowanie długo ustalone wiadomo, Scrum, który jest zobowiązanie przez zespół właścicielem produktu i klientami.Zobowiązania została zastąpiona prognozy.Mówią zespoły mogą prognozy swej pracy, że nie przekazać do niej.

Gdy rozumiem ich logiki wolę zobowiązaniom z następujących powodów:

Zobowiązuje się do elementu umieszcza zespołu w różnych mindset niż po prostu prognozowania.Jeśli prognoz zespołu, nie spełniających wszystko wspomnianej może zrobić to zachowanie dopuszczalne jest domyślna.Gdy zespoły mogą dowiedzieć się z ich prognoz, po pewnym czasie o mniej wariancję oszacowanie, znaleźć który zespoły, które prognozy zajmuje więcej czasu w celu ograniczenia wariancję w porównaniu z zespoły, które zatwierdzania.
Funkcja prognozowania lub oszacowania, jest odpowiednia dla zaległości produktu.Jednak zespoły przenoszenia wątków z zaległości produktu sprint zaległości i ich, ich dodawania następny poziom szczegółowości, znajdowanie informacji mały, umożliwiające Zadaj sobie "możemy przekazać do to?” Funkcja prognozowania narażona nastąpi powrót do stanu opóźnieniem przez zespół zamiast informacją "musimy prognozy, jest OK, jeśli firma Microsoft utracić niektóre rzeczy, firma Microsoft może poznać jego wszystkie limit później."

I na jaśniejszy Uwaga: imagine Jeśli do żona, mąż, partnera "I prognozy że będziemy razem przez dziesięć lat" a "I zatwierdzić samodzielnie użytkownikowi" — tak, które będą przekazywane źródło.

Dzięki temu Scrum dotyczy rozsądkiem.Mogę sugerowane spróbuj zarówno podejście zobowiązania, jak i podejście prognozy.To jest naukę, nie słów, jakie użycia, więc być inteligentnego, wypróbowanie obu i używać, co jest najlepsze dla użytkownika, zespołu i firmy.

Co to jest planowanie Sprintu?

Firma Microsoft przytrzymaj sprint planowania spotkania, aby zaplanować co zespołu zostanie utworzona w najbliższych sprint i jak zespołu utworzy go.Chociaż nazywamy go planowanie sprintu spotkania, faktycznie składa się z dwóch bardzo różne części.Część 1 koncentruje się na co Trwa zgłaszanie do tworzenia i zespołu uczestniczą zarówno przez właścicielem produktu i zespołem.Część 2 koncentruje się na jak plany zespołu do tworzenia żądanych funkcji.Chociaż całego zespołu muszą wziąć udział w część 2, obecności przez właściciela produktu jest opcjonalne.Jeśli z jakiegokolwiek powodu, właścicielem produktu nie weź udział w część 2, właścicielem produktu pozostają dostępne dla pytania.

W części 1 sprint planowania spotkania właścicielem produktu ma możliwość opisują zestaw żądane wątki do zespołu.Jest to sesji rozszerzony opis co część wątków.Właścicielem produktu przedstawia wątków, pokazuje sposób korzystania przez rzeczy i poprowadzi przez interfejs.Ponadto one Przejrzyj infrastruktury lub architektury elementów.Celem jest wypełnienie wystarczających informacji, że mogą oni rozpocząć oceniania, jak tworzyć funkcje głowic zbiorowy członków zespołu.Zespół poprosi różne pytania, aby zebrać informacje o jak spotkania — pytania, takie jak:

"Jak ma kryteriów akceptacji wszystkich te wątki?"
"Źródła danych, które Twoim zdaniem korzystamy?"
"Interfejs wyglądu na ten składnik?"

Podczas część 2 sprint planowania spotkania, zespół przechodzi w stan jej uwagę na tworzenie zaległości ze sprintu — listy wątków i zadań wymaganych do ukończenia je podczas sprintu.Aby zbudować zaległości, zespół dzieli każdego wątku żądany poziom zadania, właścicielem produktu Każde zadanie jest podawana oszacowanie godzinową.Do końca część 2 zespół decyduje o wątków, które go przekazać do zakończenia podczas sprintu.

Razem dwie części sprint planowania spotkania może potrwać od dwóch do 8 godzin.Ogólne zasadą używany jest, że każda część powinien wykonać jedną godzinę, przez co tydzień o długości sprint.To oznacza uruchamianie sprintach tygodniowego spotkania zajmie łącznie dwie godziny (godzinę do części 1 i godzinę dla część 2).Jeśli z drugiej strony, uruchamianie sprintach czterech tygodni, spotkania Instalacja trwa łącznie osiem godzin (cztery godziny, część 1 oraz w ciągu 4 godzin część 2).

Jak możemy ją zrobić?

Tak długo, jak zespołu pozostawia sprint planowania spotkania przekazane do zakończenia listy wątków, zespół ma osiągnąć cel Planowanie sprintu.Jednak pobierania zespołu do punktu, gdzie każdy członek zespołu zdania doświadczenia zgłaszania to zobowiązanie wymaga bitowe wstępnie planowania i ułatwienie.

Właściciel produktu ma jedno zadanie podczas planowania sprintu: się spotkania mógł opisują zestaw żądaną wątków.Celem zespołu jest zrozumienie wątki z właścicielem produktu punktu widzenia do udostępniania w wizję właścicielem produktu.ScrumMaster należy upewnić się, zadając pytania za mało i wszystkie dane wynikowe, w tym wszelkie założenia, kryteriów akceptacji i szkice Przechwytywanie zespołu.ScrumMaster pozwalać również sprawdzić, czy zespół może dodatkowe pytania po zaczyna podział pytań na zadania właścicielem produktu.Chociaż właścicielem produktu przedstawia wątki, których sumy punktu podrzędna odnosi się do zespołu historycznych, zespół ostatecznie zdecyduje czy w rzeczywistości zajmie we wszystkich wątków danej sprint, co dowie się w części 1 i 2 części sprint planowanie spotkań w oparciu o.

Po zespołu uzyskał wszystkie informacje z właścicielem produktu, jego DZIEL wątki na zadania i tworzenie zaległości sprint, które są zapisywane wszystkie wątki, uwagi, kryteriów akceptacji, zadania i szacuje dla konkretnego sprintu.Istnieje wiele sposobów, aby to zrobić, stosować się I do następującej metody pobierającej korzystać ze wszystkich członków zespołu pomysły i zapewnia każdemu głosu dekompozycji zadanie.

Ma ScrumMaster lub pośrednik w przemieszczaniu spotkania odczytać Historia i zapytaj, "Jest każdemu ją zrozumieć?" Zespół powinien, jak tylko przez czas z właścicielem produktu Omawiając go.Jeśli ktoś w zespole nie rozpoznaje, możesz wydać jakiś czas ponownie na stronie Historia, zadając pytania niezbędne właściciela produktu.
Następnie ma każdego członka zespołu, Pobierz umocowany konsoli.Poprosić każdego członka zespołu, aby zapisać jedno zadanie na każdym umocowany i toss go w środku tabeli.
- Jako każdy umocowany jest tossed do środka tabeli, thrower ogłasza zadanie.Dzięki "zaktualizować procedury składowanej" jest zapisany, ono głos.Jest to ważne, ponieważ będzie powodują pomysły i innych znaczy spowodować, "Oh tak, a my konieczne do aktualizowania źródła danych." Czy punktu, ktoś zapisze na umocowany, "zaktualizować źródła danych" at mówią i wyjątek go w środku.To działanie Diagram burzy naprawdę działa na usunięcie wszystkich skojarzonych zadań.Nie martw się o duplikaty w tej chwili.Zazwyczaj zwracania się wszystkie stickies zadanie trwa około 5-10 minut na wątku.
W przypadku stickies znajdują się już na tabeli, jest czas, można je posortować.Umieściliśmy je wszystkich programach i połączeniach na tablicy, kroku ponownie i sprawdź — partie stickies!Należy rozpocząć od zidentyfikowania duplikaty; nakładają się na siebie wszelkie stickies, które wydają się zduplikowane nazwy.Następnie Wyszukaj zadania, które wydaje się, że przejście ze sobą, ponieważ są one podobne lub są one zależne od siebie.Na przykład jeśli stickies dwa podobne relacji, umieść je razem, ale ich przesuwane jako na poniższej ilustracji pokazano:

Jeśli dwa zadania są więc pokrewne ustalić być prawie takie same, nakładają się na ich prawie w całości, jak pokazano poniżej:

Sortując stickies zespołu wybrakowane na liście zadań i wizualizację relacji między tymi pozostało na stosie.
W przypadku zadania są sortowane, jest czas oszacować.Mogę używać planowania techniki pokera do oznaczania zadania z jedną różnicą: liczby na kartach reprezentują godzin, a nie punkty.Mogę to zrobić, ponieważ użytkownicy mogą uzyskać zbyt przerwane na zbędne szczegóły dotyczące godzin, zwłaszcza w przypadku dużych ilości zadania.Jest dozwolona przyczyna ich trepidation.Zbyt często firmy za pomocą oszacowanie jako moduł walczyć zespołu."Mówiąc, który interesuje 8 godzin i możesz trwało 12.Co to jest niewłaściwy?"lub"wydanego zajmie 8 godzin i zajęło tylko 4.Użytkownik jest wypełniających oszacowania."

W ten sam sposób, że karty chronić Historia punktu abstrakcyjny szacuje, za pomocą karty do oznaczania zadania umożliwia zespół ma swobodę dołączonej o zbioru liczb stałych z plikami podczas wymuszania je na końcu dokonanie wyboru.Eliminuje żarzoną dyskusjach Określa, czy zadanie powinna być oszacowana na 6 godzin lub 6.5 godzin lub 7 godzin.

Niezależnie od ostatecznego oszacować, pamiętać, że oszacowanie jest wykonywane przez zespół i jest przeznaczony do użycia przez zespół tylko, aby pomóc zwiększyć zaufanie i określić, czy można wykonywać w niej utwór przez właściciela produktu ma pytania dla prędkości w oparciu o.Szacuje zadania nie są metryki i nie powinna być używana jako takie.Nigdy nie używać szacuje jako broń w odniesieniu do zespołu.
Teraz, kiedy szacuje zadań, zespół musi określić, jeśli jego jest w stanie wykonać więcej pracy.W tym celu należy znać wydajność zespołu, całkowitą liczbę godzin zespołu jest dostępna podczas sprintu.Określenie pojemność jest bardzo proste, jeśli masz pełne dedykowanego zespołu, ale pobiera trudniejsze, jeśli masz zespołu składa się z niepełnym osób, które są dzielone w wielu projektach.Poproś każdemu zapisują liczbę godzin, który każdy może pracować nad tym projektem na dzień (lub łącznie na sprint).Dodaj wszystkie liczby ze sobą, aby uzyskać łączną liczbę godzin, które są dostępne dla zespołu.Załóżmy, że wydajność zespołu okaże się 200 godzin.Jeśli suma zadania dla Historia jest szacowana użycie 30 godzin, poproś zespołu, "Można możemy podnieść więcej pracy?" Na tym etapie wczesnym widocznych tak.

Ponieważ większej pojemności w celu wypełnienia, przejdź do następnego wątku, a następnie powtórz kroki od 1 do 5.

(Aby uzyskać informacje dotyczące sposobu wykonania tego zadania przy użyciu programu Team Foundation Server, zobacz Współpraca (przekierowane).)

W pewnym momencie konieczne będzie trudne czas odpowiedzi na pytanie, "Można możemy podnieść więcej pracy?" Jest to spowodowane są serwisowe wydajności zespołu.Podczas pracy przez ten proces, należy wziąć pod uwagę nie chcesz wypełnić sprint do wydajności.Jeśli użytkownik może zostać szkło przypadku całkowitej, jest bardzo prawdopodobne do rozsypywać.To samo dotyczy, sprintach.Jeśli szacunkowa liczba godzin zajmują cały czas dostępne, a nowe zadanie zidentyfikowanej później w sprincie, będzie przelewał rzeczy.Należy pozostawić miejsce dla wschodzący zadania.

Biorąc pod uwagę zobowiązania sprint, pomaga należy wziąć pod uwagę retrospektywnego danych z poprzednich sprintach.Jest stale zespołu konieczności wyświetlone w pracy?Być może zespołu można zadeklarować więcej podczas planowania sprintu.Zespół jest stale nie można zakończyć wszystkie pracy dla sprintu?Zespół może być konieczne być bardziej ostrożną z jego zobowiązania, dopóki nie kierowany jest głównej przyczyny sprintach ukończona.

Jednym ze sposobów umieścić wiele na pytanie "jak pełnych do wypełnienia swoje szkło" jest należy wziąć pod uwagę wzrost rozmiaru planu.Wzrost rozmiaru plan mierzy, jak rzeczywiste godziny pracy poświęca Porównaj, aby szacuje początkowej.Załóżmy, na przykład, że nasz zespół ma pojemność 200 dostępnych godzin.Zespół zobowiązuje się do co jego zdaniem będzie 190 godzin, szacunkowy.Na końcu sprint zespołu oblicza te wątki znajdujących się przez które 240 rzeczywiste godziny pracy, co spowoduje wzrost rozmiaru planu, 20%.

Zespół, który umożliwia znalezienie tę rozbieżność powinien wymaga więcej czasu podczas retrospektywne badaniu powodów:

Są odnajdywane podczas wykonywania, które nie zostały określone podczas planowania zbyt wiele zadań?
Zespół niedoszacowania zadań opiera się na jego bieżącego zestawu?
Czy zespół overestimate pojemności?
I tak dalej.

Zespół również należy wziąć pod uwagę jej wzrost rozmiaru plan podczas kolejny sprint planowania spotkania podczas ustalania, czy można przekazać do wątku.Przejdź do naszego przykład, jeśli zespół nadal szacuje pojemności 200 godzin, zespół powinien Odejmij 20% wyłączenia od góry do wyrównania danych historycznych w oparciu o wzrost rozmiaru plan "oczekiwanym".Innymi słowy, dla co najmniej tego sprintu, aby zapobiec wypływów, gdy zespołu pobiera 160 godzin, jego powinna deklarować się z wydajnością.

Biorąc pod uwagę wzrost rozmiaru plan jest określenie sposobu pełną sprint jeden ze sposobów powinna być.Może wykorzystać, jednak, że celem nie jest dokładnie odpowiadać pojemności.Jest to raczej umożliwia zespołowi zaznaczać w zobowiązuje się do odpowiedniej liczby wątków — liczba, która wypycha zespołu bez nadmiernego obciążania go.Plan wzrost rozmiaru to po prostu sposób określić, kolejny sprint około jak pełną powinien być, czy innych czynników pozostają takie same.

Gdy wszystkie wątki szacuje lub cały czas jest używane przez wątki, wróć do właścicielem produktu i udostępnić zaległości sprint, który zespołu została zatwierdzona do świadczenia.Sprintu rozpoczyna się teraz — tak rozpocząć pracę!

Typowych problemów

W moich lat konsultacji z zespołami, aby pomóc im przyjęcie Scrum przejrzane wiele takie same problemy, które uniemożliwiają pomyślne sprint planowania.Chociaż planowanie sprintu wydaje się bardzo proste, zespoły, które są właśnie wprowadzenie do korzystania z Scrum zwykle wystąpić problemy.Wiele z tych problemów i ich potencjalne rozwiązania są wyszczególnione w tej sekcji.

Scenariusz: Zespołu nie można przekazać do wszystkich wątków, który zgłosił żądanie właścicielem produktu.

Powinien oczekiwać, aby tak się stało od czasu do czasu.Zespół może wykonać kopię zapasową zobowiązaniom z danymi z kroki 4 i 5 wcześniej w tym temacie, właścicielem produktu powinna być spełniony.Należy zachować oka się, aby upewnić się, że ten błąd, aby zatwierdzić nie jest wynik za duży wypełniających lub duże zadania.ScrumMaster powinien wezwania, co wydaje się być nadmiernie konserwatywnego szacuje, aby upewnić się, że są one dokładne.Właścicielem produktu należy pytanie dowolnym zadaniem, które ma oszacowanie dwóch cyfr.Każde zadanie jest szacowana dostarczane później niż powinien być rozbiciu na mniejsze zadania i ponownie szacowany dwóch dni roboczych.Ma wartość true dla wszystkich projektów, ale jest szczególnie Deprymujące dla zespołów uruchomiony sprintach tygodniowego lub dwóch tygodni.

Scenariusz: Właścicielem produktu nie pochodzi przygotowane.

Jedną wartość Scrum jest względem.Jest adresem do spotkania nieprzygotowany disrespectful.Dlatego co to jest zespołu zrobić, jeśli właścicielem produktu pojawia się bez informacji zespołu wymaga?Chociaż jedną z opcji jest odłożyć spotkania, dopóki właścicielem produktu jest gotowa na, to tylko zachęca samo — uniknąć tego problemu.Inną opcją jest Anuluj sprintu.To może pracować, ale jest extreme.

Najlepszym rozwiązaniem dwukrotne się znaleźć.Pierwszy, zaległości produktu powinien się w kolejności priorytetu jakieś, właścicielem produktu nie ma określony zestaw wątki, zespołu i właścicielem produktu po prostu można omawiać wątków w kolejności priorytetu, aż do osiągnięcia punktu, w którym zdaniem będzie na lub poza pojemności.Zespół mogą następnie wybrać dokładną zobowiązaniom podczas część 2 spotkania, jak zwykle.

Po zakończeniu spotkania, ScrumMaster powinny działać zrozumieć, dlaczego nie został przygotowany właścicielem produktu.Jeżeli ten problem braku zaangażowania, ScrumMaster nauczyć właścicielem produktu na ważności już wkrótce będzie spotkania przygotować ze zbioru wątków.If, on the other hand, the problem was that the product owner was unable to prepare, perhaps because the team failed to help with grooming, the ScrumMaster should help to solve those problems as well.

Scenariusz: Część 1 przekracza jego timebox.

Inną wartość to okno.Jeśli część 1 spotkania działa, jest objawowych braku fokusu.Czasami właścicielem produktu jest niezogniskowane z powodu braku przygotowania priorytetyzacja i próby wyjaśniają zbyt dużej liczby wątków.Inne czasy Brak fokus może pochodzić z zespołem wymknięciu "jakie" rozmowy z charakterystykę "jak".

ScrumMaster powinna ułatwiać przenosić elementy przez istniejących, że tabeli właścicielem produktu żadnych wątków, które nie może być w pełni wyjaśniono i że zespół Zatrzymaj szczegółowe dyskusje implementacji się część 1.Jeden prosty niezogniskowane dyskusji jest poprawka do użycia stoper lub zegar.

Scenariusz: Część 2 przekracza jego timebox.

Ponownie szczególny nacisk położono.Jeśli masz zespołu, który zawiera partii, czasami posiadające dziedzinę limitu Dyskusje jest wszystkie niezbędne do wprowadzenia spotkania w wierszu.Przesuń minutnika i ustaw konwersacji na minutę lub dwie między szacuje zadanie.Celem jest dokładność, nie dokładności 100%.

Inne czasy braku fokus podczas część 2 jest objawowych braku pielęgnacji podczas wykonywania sprint zaległości produktu.Pielęgnacja jest gdy zespołu może wyglądać w przyszłości wątki i pracować z właścicielem produktu do dodania wątków lub kołkami przypinanie w dół kierunkach projektu lub opracowywania architektury pytania.Bez pielęgnacji zaległości produktu regularne planowania zaległości sprint staje się niewygodna i bolesnej.

Scenariusz: Właścicielem produktu nie jest dostępny.

Jeśli właścicielem produktu nie może uczestniczyć w spotkaniu w jakikolwiek sposób, nie wyznaczony serwer proxy działa tak, jakby właścicielem produktu dołączone do spotkań nieprzygotowany.Praca za pomocą pierwszych elementów i przekazać do ich zalety, można.Być może wydawać się zmienić od godziny spotkania, aby uwzględnić harmonogram właścicielem produktu.Nie.Przesunięcie godziny spotkania uwzględnia potrzebę jednego koszt wielu.Nie jest opłaca.

Scenariusz: Zespół nie ma wymaganych kryteriów akceptacji.

Mogę zawsze poinformowania zespoły do poproś właściciela produktu podczas część 1, "jak ma kryteriów akceptacji dla tego?" lub "Co potrzebujemy uzyskać zaakceptowania utworu?" Jeśli to brakuje w części 2, określając zespołu jest zadań, zespół ma nie wiadomo jak uzyskać wątku, aby zamknąć.Jeśli zespół ma odgadnąć, co istnieje w części 1 w oparciu o zespołu narażona jest właścicielem produktu podejmowania decyzji o na końcu sprint wątku nie zostało zakończone.Poproś o kryteriów akceptacji od początku dla każdego wątku.ScrumMasters — autokarowych swojego produktu, który mógłby podać te dane.

Scenariusz: Właścicielem produktu nie może ustalić oznacza co zrobić.

Tak samo, jak zespołu chce kryteriów akceptacji, właścicielem produktu wymaga aktualności opisu jakie zespołu oznacza przez "wątku jest wykonywane". Ta lista gotowe, należy wyraźnie opublikowane, aktualne i dostępne dla właścicielem produktu przez cały czas.Nieaktualne listy zadań zrealizowanych utrudnia to plan, ponieważ nie istnieje żadne zrozumienie dotyczących gotowe wygląd.Należy upewnić się, który aktualizowania listy zadań zrealizowanych jest częścią każdej oceny sprint lub retrospektywnego.

Scenariusz: Właściciela ScrumMaster lub produktu jest szacowanie/wpływające na pracy szacuje zespołu.

Witamy w części 2 spotkania jest właścicielem produktu, ale właścicielem produktu roli w części 2 powinny być ograniczone do wyjaśnienia wymagania lub opracowywania konkretne pytanie.Właścicielem produktu należy nigdy nie zakłóca Dyskusja zespołu sposób implementowania Historia, nie ma żadnych powiedz w oszacowanie zadania.Właściciel produktu musi zaufania zespołowi wykonują pracę.

Jeśli właścicielem produktu działa poza tymi wytycznymi, ScrumMaster powinien autokarowych właścicielem produktu do bardziej odpowiednie roli.Jeśli właścicielem produktu odrzuca więcej pasywnego roli, ScrumMaster ma uprawnienia do poproś właściciela produktu, aby pozostawić.

Planowanie sprintu musi być trudne.Często jest możliwości i godzinę cały Scrum zespołu do tworzenia camaraderie przez pracy zebranie w odpowiedzi na pytanie "Co możemy przekazać do?" Należy pamiętać, że jeśli okaże się, że spotkań Uruchom długie, główny powodujących problemy będące przyczyną prawdopodobnie to.Jeśli jesteś ScrumMaster, pozostaw spotkanie koncentruje się, ponieważ gwarantuje, że właścicielem produktu i zespołem oczyszczenie zaległości produktu.Pomoc właścicielem produktu pochodzą przygotowany przez o gotowy, zanim spotkania kryteriów akceptacji wątku.Na koniec Zapewnij właścicielem produktu i zespołem koncentruje się na zadaniu — określania, jakie one przekazać do sprintu.