Sprint, planowanie

Artykuł
04/10/2013

autorstwa Mitcha Laceya.Właściciel, Mitch Lacey & Associates, Inc. Firma specjalizuje się w przyjmowaniu i ulepszaniu Agile i Scrum.

Styczeń 2012 r.

Planowanie sprintu nie musi być trudne.Często jest wesołe i przyjemne dla całego zespołu scrumowego budowanie koleżeństwa przez pracę razem w celu odpowiedzenia na pytanie „Do czego możemy się zobowiązać?”. W tym artykule autorzy podają przykłady i strategie, jak utrzymać ukierunkowanie i skuteczność planowania sprintu, oraz podają szczegóły potencjalnych rozwiązań typowych problemów napotykanych przez zespoły podczas planowania sprintów.

Dotyczy

Zarządzanie cyklem eksploatacji aplikacji; Team Foundation Server

W tym artykule:

Wprowadzenie
Prognozowanie a przydzielanie
Co to jest planowanie sprintu?
Jak możemy to osiągnąć?
Typowe problemy
- Scenariusz: Zespół nie może podjąć działań w stosunku do wszystkich wątków żądanych przez właściciela produktu.
- Scenariusz: Właściciel produktu przybył nieprzygotowany.
- Scenariusz: Część 1 przekracza jego ramy czasowe.
- Scenariusz: Część 2 przekracza jego ramy czasowe.
- Scenariusz: Właściciel produktu jest niedostępny.
- Scenariusz: Zespół nie posiada potrzebnych kryteriów przyjęcia.
- Scenariusz: Właściciel produktu nie wie, co oznacza „wykonano”.
- Scenariusz: Właściciel ScrumMaster lub właściciel produktu szacuje/wpływa na szacunki/pracę zespołu.
Wnioski

Nie planujemy.Stosujemy Scrum, dlatego wystarczy wykonać.

Słyszę to cały czas.Ludzie uważają, że Scrum i Agile nie wymagają planowania, szacowania, żadnych spotkań, słowem — niczego.Nie może to być dalsze od prawdy.Planujemy na różnych poziomach elastycznego projektu: dzienny plan lub dzienny standup, tygodniowe plany (zaległości, sprintu lub iteracji), planowanie wydań (zaległości produktu) i potencjalnie więcej.

Skupmy się na planowaniu sprintu.

Prognozowanie a przydzielanie

W lecie 2011 r. Ken Schwaber i Jeff Sutherland poprawili swój Przewodnik po metodyce Scrum.W niej usunięto jedno wieloletnie zachowanie znane metodzie Scrum, którym jest zobowiązanie podejmowane przez zespół wobec właściciela produktu i klientów.Zobowiązanie zostało zastąpione przez prognozę.Mówią, że zespoły mogą prognozować swoją pracę, ale nie zatwierdzać ją.

Chociaż rozumiem ich logikę, wolę zobowiązanie z następujących powodów:

Zobowiązanie się do czegoś wprowadza zespół w inny sposób myślenia niż tylko prognozowanie.Jeżeli prognozuje zespół, przyjmuje się, że niespełnienie wszystkiego, co powiedział, że jest w stanie zrobić, jest akceptowalnym zachowaniem.Chociaż zespoły mogą uczyć się ze swoich prognoz, ostatecznie mając mniejszą wariancję szacowania, zespoły, które prognozują tracą więcej czasu na zmniejszenie wariancji w porównaniu z zespołami, które zatwierdzają.
Prognozowanie, lub szacowania, jest właściwe dla zaległości produktu.Jednak gdy zespoły przenoszą historyjki z zaległości produktu do zaległości sprintu i je dzielą, dodają kolejny poziom szczegółowości, dowiadując się drobnych szczegółów, które pozwolą im zadać sobie pytanie „czy możemy się do tego zobowiązać?”. Prognozowanie niesie ryzyko powracania do stanu opóźnienia przez zespół, który zaczyna mówić „potrzebujemy tylko prognozy, jest OK, jeśli coś przegapimy, rozpoznamy to wszystko później.”

A w lżejszym tonie: wyobraź sobie, że mówisz do żony, męża lub partnera „Prognozuję, że będziemy wspólnie przez dziesięć lat”, zamiast „Będę z Tobą na zawsze” — tak, to na pewno zostanie dobrze przyjęte.

W ostatecznym rozrachunku metodyka Scrum opiera się na zdrowym rozsądku.Sugeruję wypróbowanie podejścia ze zobowiązaniem i podejścia prognostycznego.Chodzi tylko o naukę, nie o słowa, których używasz, więc bądź sprytny, eksperymentuj z jednym i drugim i używaj tego, co jest najlepsze dla Ciebie, Twojego zespołu i firmy.

Co to jest planowanie sprintu?

Mamy spotkanie sprintu w sprawie zaplanowania co zespół zbuduje w nadchodzącym sprincie i jak to zbuduje.Mimo że nazywamy to spotkaniem dotyczącym planowania sprintu, faktycznie składa się ono z dwóch bardzo różnych części.Część 1 dotyczy tego, co zespół ma do stworzenia, a bierze w niej udział właściciel produktu oraz zespół.Część 2 dotyczy tego, jak zespół planuje utworzyć pożądaną funkcję.Chociaż cały zespół musi uczestniczyć w części 2, obecność właściciela produktu jest opcjonalna.Jeśli z jakiegokolwiek powodu właściciel produktu nie uczestniczy w części 2, właściciel produktu powinien pozostać dostępny dla pytań.

W części 1 spotkania poświęconego planowania sprintu właściciel produktu ma okazję opisać żądany zestaw historyjek zespołowi.Jest to dogłębna sesja na temat tego co część wątków.Właściciel produktu przedstawia historie, pokazuje sposób interakcji i omawia interfejs.Ponadto mogą one przeglądać elementy infrastruktury lub architektury.Celem jest przekazanie wszystkim członkom zespołu wystarczających informacji, aby mogli oni rozpocząć analizę sposobu zaimplementowania funkcjonalności.Zespół zada szereg pytań, aby zgromadzić informacje dla jak spotkania — pytania, takie jak:

„Jakie są kryteria akceptacji wszystkich tych artykułów?”
„Których źródeł danych myślisz, że używamy?”
„Jak powinien wyglądać interfejs w tym składniku?”

W części 2 spotkania poświęconego planowaniu sprintu zespół kieruje uwagę na sporządzenie zaległości sprintu — listy historyjek i zadań wymaganych do ich ukończenia podczas sprintu.Aby zbudować zaległości, zespół dzieli każdy wątek, którego zażądał właściciel produktu do poziomu zadania; dla każdego zadania podano godzinowe szacowanie.Pod koniec części 2 zespół decyduje, które historyjki można zatwierdzić do ukończenia podczas sprintu.

Razem dwie części spotkania poświęconego planowaniu sprintu mogą potrwać od dwóch do ośmiu godzin.Ogólna reguła kciuka, z której korzystam, polega na tym, że każda z części powinna zająć jedną godzinę w tygodniu sprintu.To oznacza, że jeżeli prowadzę jednotygodniowy sprint, spotkanie będzie trwało dwie godziny (jedna godzina na Część 1 i jedna na Część 2).Jeśli z drugiej strony stosuję głównie sprinty czterotygodniowe, spotkanie zajmie łącznie osiem godzin (cztery godziny na część 1 i cztery godziny na część 2).

Jak możemy to osiągnąć?

O ile tylko zespół opuszcza spotkanie poświęcone planowaniu sprintu zaangażowany w wykonanie listy historyjek, osiągnął cel planowania sprintu.Dotarcie z zespołem do punktu, gdzie każdy członek zespołu nie obawia się podjąć tego zobowiązania, wymaga jednak pewnego wstępnego planowania i wsparcia.

Właściciel produktu ma jedno zadanie podczas planowania sprintu: uczestniczyć w spotkaniu, aby opisać zestaw żądanych historyjek.Celem zespołu jest zrozumienie wątków z punktu widzenia właściciela produktu, aby móc dzielić jego wizję.Mistrz Scrum powinien upewnić się, że zespół zadaje wystarczająco dużo pytań i przechwytuje wszystkie dane wynikowe, w tym kryteria akceptacji, szkice i wszelkie założenia.Mistrz Scrum zawiadamia także właściciela produktu, że zespół może mieć dodatkowe pytania, po rozpoczęciu podziału pytań na zadania.Chociaż właściciel produktu przedstawia historyjki, których sumy punktów odpowiadają mniej więcej historycznej prędkości pracy zespołu, zespół ostatecznie decyduje, czy w rzeczywistości może zająć się wszystkimi historyjkami w danym sprincie na podstawie tego, czego dowie się w częściach 1 i 2 spotkania dotyczącego planowania sprintu.

Gdy zespół uzyska wszystkie informacje od właściciela produktu, musi podzielić historyjki do poziomu zadań i stworzyć zaległość sprintu, który przechwytuje wszystkie historyjki, notatki, kryteria akceptacji, zadania i oszacowania dla danego sprintu.Chociaż istnieje wiele sposobów, stosuję następującą metodę, która wykorzystuje wszystkie pomysły członków zespołu i wszystkim daje głos w dekompozycji zadania.

Niech Scrum Master lub organizator spotkania odczyta historyjkę i zapyta „Czy wszyscy to rozumieją?” Zespół powinien, ponieważ właśnie spędził czas z właścicielem produktu nad omawianiem jej.Jeśli ktoś w zespole nie rozumie, należy poświęcić trochę czasu na ponowne omówienie historyjki, zadając wszelkie konieczne pytania właścicielowi produktu.
Następnie niech każdy członek zespołu chwyci przylepną podkładkę.Poproś każdego członka zespołu o zapisanie pojedynczego zadania na każdej karteczce, po czym rzuć ją na środek stołu.
- Wraz z rzucaniem kolejnych samoprzylepnych karteczek na środek stołu osoba rzucająca ogłasza zadania.Jeśli więc napisane jest „procedura składowana aktualizacji”, jest wypowiadana na głos.Jest to istotne, ponieważ będzie inspirowało pomysły i spowodowało, że inni będą mówić „Och tak, musimy jeszcze zaktualizować źródło danych". W tym momencie, ktoś zapisze na karteczce samoprzylepnej „aktualizacja źródła danych", wypowiedz te słowa i umieść ją na środku.To działanie burzy mózgów naprawdę działa w kontekście pozbywania się skojarzonych zadań.W tej chwili nie martw się o duplikaty.Odrzucenie wszystkich karteczek zadania zazwyczaj zajmuje około pięciu do dziesięciu minut na historyjkę.
Gdy wszystkie karteczki znajdują się w tabeli, jest już czas, aby je posortować.Powieś wszystkie na ścianie, zrób krok w tył i patrz — mnóstwo karteczek samoprzylepnych!Zacznij od określenia jakichkolwiek duplikatów, nałóż kartki, które wydają się duplikatami.Następnie wyszukaj zadań, które wydają się być zbliżone, ponieważ są one podobne lub są zależne od siebie.Na przykład jeśli dwie karteczki mają podobne relacje, umieść je razem, ale przesuń, jak na poniższej ilustracji pokazano:

Jeśli dwa zadania są tak ściśle powiązane, że niemal identyczne, nałóż je na siebie prawie całkowicie, jak pokazano poniżej:

Sortując karteczki, zespół może redukować listę zadań i wizualizować relacje między tymi, które pozostają.
Po posortowaniu zadań jest czas na oszacowanie.Używam techniki pokera planującego do oszacowania zadań, z jedną różnicą: liczby na kartkach reprezentują godziny, a nie punkty.Robię to, ponieważ ludzie zbyt często poświęcają się zbędnym szczegółom mimo ograniczeń czasowych, szczególnie w dużych zadaniach.Istnieje dobry powód ich lęku.Zbyt często oszacowanie służy firmom do karania zespołu.„Miało to potrwać 8 godzin, a zajęło Ci 12.Co się stało?" lub "Miało to zająć 8 godzin, a zajęło tylko 4.Użytkownik uzupełnia swoje oszacowania."

W ten sam sposób, jak karty pomagają zachować abstrakcyjność oszacowań punktów historyjek, szacowanie zadań przy użyciu kart daje zespołowi swobodę wynikającą z posiadania zbioru stałych liczb, spośród których można wybierać, wymuszając przy tym ostatecznie dokonanie wyboru.Także eliminuje gorące dyskusje, czy zadania należy oszacować na 6 godzin, 6,5 godziny czy 7 godzin.

Niezależnie od ostatecznego oszacowania, należy pamiętać, że szacowanie jest wykonywane przez zespół i ma być używane przez zespół tylko aby pomóc zwiększyć zaufanie i określić, czy zespół może wykonać pracę określoną przez właściciela produktu w oparciu o prędkość.Szacunki zadania nie są metrykami i nie powinny być używane jako takie.Nigdy nie używaj oszacowania jako broni przeciwko zespołowi.
Teraz gdy zadania są oszacowane, zespół musi określić, czy posiada możliwości do podjęcia więcej pracy.Aby to zrobić, trzeba znać wydajność zespołu, całkowitą liczbę godzin, którymi dysponuje zespół podczas sprintu.Określanie możliwości jest łatwe, jeśli masz w pełni dedykowany zespół, ale staje się trudniejsze, jeśli zespół jest złożony z osób w niepełnym wymiarze godzin, które uczestniczą w wielu projektach.Poproś wszystkich o zanotowanie liczby godzin, jaką mogą pracować nad projektem dziennie (lub łącznie w sprincie).Dodaj wszystkie liczby razem, aby uzyskać całkowita liczbę godzin dostępnych dla zespołu.Załóżmy, że możliwości zespołu okazują się wynosić 200 godzin.Jeśli szacuje się, że suma zadań dla historyjki zajmie 30 godzin, zapytaj zespół „Czy możemy wziąć jeszcze więcej pracy?”. Na tym wczesnym etapie odpowiedzią jest zdecydowane tak.

Ponieważ masz więcej możliwości, które można zapełnić, przejdź do następnej historyjki i powtórz kroki od pierwszego do piątego.

(Aby uzyskać informacje dotyczące sposobu wykonania tego zadania przy użyciu programu Team Foundation Server, zobacz Planowanie Agile i iteracje.)

W pewnym momencie będziesz mieć problem z odpowiadaniem na pytanie „Czy możemy wziąć jeszcze więcej pracy?”. Jest tak, ponieważ zbliżasz się do granic możliwości zespołu.Wykonując kolejne prace w tym procesie, weź pod uwagę, że nie chcesz wypełniać sprintu co końca jego możliwości.Jeśli wypełnisz szklankę wodą po brzegi, jest prawdopodobne, że się rozleje.Dotyczy to także sprintów.Jeśli szacowana liczba godzin zajmie cały dostępny czas i nowe zadanie zostanie zidentyfikowane później w sprincie, sprawy wymknął się spod kontroli.Należy pozostawić miejsce na nowe zadania.

Biorąc pod uwagę zobowiązanie sprintu, może to ułatwić uwzględnienie retrospektywnych danych z dawnych sprintów.Czy zespół musi stale pracować coraz więcej?Prawdopodobnie zespół mógłby bardziej się zaangażować w trakcie planowania sprintów.Czy zespół regularnie nie jest w stanie zakończyć całej pracy w sprincie?Zespół być może będzie musiał być bardziej ostrożny w podejmowaniu zobowiązań, dopóki nie zajmie się główną przyczyną niekompletnych sprintów.

Jedym ze sposobów na rozwiązanie problemu „w jakim stopniu napełnić szklankę” jest rozważenie rozrostu planu.Rozrost planu mierzy, jak mają się rzeczywiste spędzone godziny do początkowych szacunków.Załóżmy na przykład, że nasz zespół ma możliwości 200 dostępnych godzin.W oparciu o szacunki, zespół przeznacza 190 godzin.Na końcu sprintu zespołu oblicza, że te historyjki zawierały 240 rzeczywistych godzin pracy, co spowodowało wzrost rozmiaru planu o 20%.

Zespół, który znajdzie tę rozbieżność, powinien poświęcić trochę czasu na etapie retrospekcji, analizując przyczyny:

Czy jest zbyt wiele zadań wykrywanych podczas wykonywania, które nie zostały zidentyfikowane podczas planowania?
Czy zespół niedoszacowuje zadania w oparciu o swój obecny zestaw umiejętności?
Czy zespół przecenił swoje możliwości?
I tak dalej.

Podczas oceny możliwości zaangażowania w wątek, zespół powinien również rozważyć wzrost rozmiaru swojego planu podczas następnego spotkania planującego sprint.Wracając do naszego przykładu, jeśli zespół nadal szacuje możliwości na 200 godzin, powinien odjąć 20% od góry, aby skompensować „oczekiwany” rozrost planu na podstawie danych historycznych.Innymi słowy, dla co najmniej tego sprintu, aby zapobiec wymknięciu się spod kontroli, kiedy zespół dojdzie do 160 godzin, powinien zadeklarować osiągnięcie pułapu możliwości.

Uwzględnienie rozrostu planu jest jednym ze sposobów określenia ilościowego, jak pełny sprint powinien być.Należy jednak mieć świadomość, że celem nie jest dokładne odpowiadanie pojemności.Lepiej, aby zespół mógł zająć się odpowiedną liczbą wątków — taką, która pozwala zespołowi się rozwijać, ale nie przeciąża go.Rozrost planu jest tylko sposobem na określenie w przybliżeniu, jak pełny powinien być następny sprint, jeśli inne czynniki pozostają równe.

Gdy wszystkie wątki są szacowane lub cały czas jest zużywany przez wątki, wróć do właściciela produktu i udostępnij zaległości sprintu, które zespół zobowiązał się do dostarczenia.Sprint właśnie się rozpoczyna — do pracy!

Typowe problemy

W ciągu wielu lat doradzania zespołom, aby pomóc im przyjąć metodykę Scrum, widziałem wiele takich samych problemów, które uniemożliwiają pomyślne planowanie sprintów.Chociaż planowanie sprinty wydaje się proste, zespoły, które po raz pierwszy stykają się z metodyką Scrum, zwykle mają kłopoty.Wiele z tych problemów i ich potencjalnych rozwiązań zostało wyszczególnionych w niniejszej sekcji.

Scenariusz: Zespół nie może podjąć działań w stosunku do wszystkich wątków żądanych przez właściciela produktu.

Należy się spodziewać, że czasami się to zdarza.Tak długo, jak zespół potrafi wspierać deklaracje zaangażowania danymi z wcześniejszych kroków czwartego i piątego, właściciel produktu powinien być zadowolony.Warto przyglądać się temu, aby zapewnić, że ten błąd nie jest wynikiem nadmiernego uzupełniania lub dużych zadań.Mistrz Scrum powinien sprawdzać oszacowania, które wydają się być nadmiernie ostrożne, aby upewnić się, że są one właściwe.Właściciel produktu powinien zadawać pytanie o każde zadanie z szacowanym dwucyfrowym nakładem pracy.Każde zadanie szacowane na dłużej niż dwa dni robocze należy podzielić na mniejsze zadania i ponownie oszacować.Dotyczy to wszystkich projektów, ale jest szczególnie trudne dla zespołów przeprowadzających jedno- i dwutygodniowe sprinty.

Scenariusz: Właściciel produktu przybył nieprzygotowany.

Jedną wartością Scrum jest szacunek.Jest brakiem szacunku przyjście na spotkanie nieprzygotowanym.Co więc ma zrobić zespół, jeśli właściciel produktu nie przedstawia informacji, która jest potrzebna zespołowi?Chociaż jedną z opcji jest odroczenie spotkania, aż właściciel produktu będzie gotowy, czyniąc to, tylko zachęca się do takiego samego zachowania — unikania.Inną opcją jest anulowanie sprintu.Chociaż może to działać, jest ekstremalnym rozwiązaniem.

Stwierdzam, że najlepsze rozwiązanie jest dwutorowe.Po pierwsze zaległości produktu powinny być w jakimś priorytecie kolejności, więc jeśli właściciel produktu nie ma określonego zestawu historyjek, zespół i właściciel produktu mogą omawiać historyjki według kolejności priorytetów, aż do osiągnięcia punktu, gdzie uważają, że osiągnęli lub przekroczyli poziom możliwości.Zespół może następnie podjąć decyzję w sprawie dokładnej formy zaangażowania podczas 2. części spotkania, jak zazwyczaj.

Po spotkaniu Scrum Master powinien działać w celu zrozumienia, dlaczego właściciel produktu nie był przygotowany.Jeśli problemem był brak zaangażowania, Scrum Master może pouczyć właściciela produktu o wadze przychodzenia na spotkanie z zestawem przygotowanych historyjek.Jeżeli z drugiej strony problemem było, że właściciel produktu nie był w stanie się przygotować, prawdopodobnie ponieważ zespół nie pomógł z porządkowaniem, Scrum Master powinien pomóc rozwiązać również te problemy.

Scenariusz: Część 1 przekracza jego ramy czasowe.

Inną wartością jest fokus.Jeśli część 1 spotkania się przeciąga, jest to objaw braku koncentracji.Czasami właściciel produktu jest rozkojarzony ze względu na brak przygotowania, nieustalanie priorytetów lub próbę wyjaśnienia zbyt wielu wątków.W innym przypadku brak fokusu może być spowodowany sposobem prowadzenia konwersacji zamiast skupiania się na ich treści.

Mistrz Scrum powinien usprawniać działania, poprzez wymaganie, żeby właściciel produktu umieszczał w tabeli wszystkie wątki, które nie mogą być wyjaśnione w pełni oraz wymaganie, aby zespół prowadził szczegółowe dyskusje dotyczące wdrażania poza częścią 1.Prostą metodą na uporządkowanie dyskusji jest użycie stopera lub zegarka.

Scenariusz: Część 2 przekracza jego ramy czasowe.

Ponownie — koncentracja.Jeśli masz zespół, który dużo rozmawia, czasami zwykłe wprowadzenie dyscypliny ograniczającej dyskusje wystarcza, aby sprowadzić spotkanie na właściwe tory.Przynieś stoper i ogranicz rozmowę do jednej lub dwóch minut między szacowaniami zadań.Celem jest dokładność, a nie precyzja 100%.

W innym przypadku brak fokusu w Części 2 oznacza brak porządkowania zaległości produktu podczas wykonywania sprintu.Porządkowanie to czas, gdy zespół może przyjrzeć się przyszłym historyjkom i pracować z właścicielem produktu nad dodaniem historyjek lub próbek w celu wiążącego ustalenia kierunków projektowania lub znalezienia odpowiedzi na pytania dotyczące architektury.Bez regularnego oczyszczania zaległości produktu planowanie zaległości sprintu staje się niewygodne i żmudne.

Scenariusz: Właściciel produktu jest niedostępny.

Jeśli właściciel produktu nie może uczestniczyć w spotkaniu z jakiegokolwiek powodu i nie wyznaczył pełnomocnika, działaj tak, jakby właściciel produktu przyszedł na spotkanie nieprzygotowany.Zajmij się najważniejszymi elementami i potwierdź je, jak można najlepiej.Być może zajdzie potrzeba zmiany czasu spotkania, aby dostosować harmonogram właściciela produktu.Nie.Przesuwanie czasu spotkania uwzględnia potrzeby jednej osoby kosztem innych.To nie jest tego warte.

Scenariusz: Zespół nie posiada potrzebnych kryteriów przyjęcia.

Zawsze doradzam zespołom, aby pytały właściciela produktu w części 1 „Jakie są kryteria akceptacji?” lub „Co musimy zrobić, abyście zaakceptowali produkt końcowy?” Jeśli tego brakuje w części 2, gdy zespół określa zadania, zespół nie będzie miał pojęcia, jak zamknąć historyjkę.Jeśli zespół musi zgadywać w oparciu o wyjaśnienia z części 1, istnieje ryzyko, że właściciel produktu na końcu sprintu podejmie decyzję, że historyjka nie jest zakończona.Proś o kryteria akceptacji od początku każdej historyjki.ScrumMasters — przeszkol swoich właścicieli produktu, aby dostarczali te dane.

Scenariusz: Właściciel produktu nie wie, co oznacza „wykonano”.

Podobnie jak zespół chce kryteriów akceptacji, właściciel produktu zasługuje na aktualny opis tego, co zdaniem zespołu oznacza „historyjka jest gotowa”. Ta lista gotowych produktów musi być wyeksponowana, aktualna i dostępna dla właściciela produktu przez cały czas.Nieaktualna lista gotowych produktów utrudnia planowanie, ponieważ nie ma wspólnej interpretacji co do kształtu gotowych elementów.Pamiętaj, że aktualizacja listy gotowych produktów jest częścią każdej oceny sprintu lub retrospektywy.

Scenariusz: Właściciel ScrumMaster lub właściciel produktu szacuje/wpływa na szacunki/pracę zespołu.

Właściciel produktu jest mile widziany w drugiej części spotkania, ale jego rola w tej części powinna być ograniczona do wyjaśnienia wymagań i odpowiadania na określone pytania.Właściciel produktu nigdy nie powinien przeszkadzać zespołowi w dyskusji nad sposobem implementacji historyki i nie ma prawa głosu przy szacowaniu zadania.Właściciel produktu musi ufać zespołowi wykonującemu pracę.

Jeśli właściciel produktu działa poza tymi wytycznymi, Scrum Master powinien zaproponować właścicielowi produktu bardziej właściwą rolę.Jeżeli właściciel produktu odmawia przyjęcia bardziej pasywnej roli, Scrum Master ma prawo poprosić właściciela produktu o opuszczenie sali.

Planowanie sprintu nie musi być trudne.Często jest wesołe i przyjemne dla całego zespołu scrumowego budowanie koleżeństwa przez pracę razem w celu odpowiedzenia na pytanie „Do czego możemy się zobowiązać?”. Pamiętaj, że jeśli stwierdzisz, że Twoje spotkania trwają za długo, prawdopodobnie powodują to główne przyczyny problemów.Jeśli jesteś Scrum Masterem, zachowaj odpowiedni punkt skupienia spotkania poprzez zapewnienie, że właściciel produktu i zespół przygotowują zaległość produktu.Pomagają właścicielowi produktu przychodzić przygotowanemu przez przygotowanie kryteriów akceptacji historyjki przed spotkaniem.Wreszcie pomóż właścicielowi produktu i zespołowi skupić się na wykonywanym zadaniu — określając, do czego mogą się zobowiązać w trakcie sprintu.