Scrum Master

Klienci

Właściciel produktu

Użytkownicy

Developerzy

Złożony

Zdefiniowany

Hybrydowy

Empiryczny

Developerzy oraz Scrum Master

Developerzy oraz Product Owner.

Developerzy

Zespół Scrumowy.

Scrum Master oraz Product Owner.

Upewnia się, że każdy członek zespołu odpowiada na 3 pytania

Zbiera i raportuje do managementu informacje o statusie i postępie

Nie musi tak być, jego zadaniem jest upewnienie się iż Daily się odbywa i ma właściwy cel

Zapisuje każde zmiany w Sprint Backlogu oraz dodaje do niego nowe elementy, śledzi również postęp za pomocą burn-down

Jest możliwy do wydania i dostarczenia końcowym klientom

Jest możliwy do przekazania Product Ownerowi do testów akceptacyjnych

Jest możliwy do zintegrowania z innymi Przyrostami dostarczonymi przez inne zespoły

Wszystkie punkty z Definicji ukończenia są ukończone

Praca developerska jest ukończona i Przyrost może być testowany w następnym Sprincie

Zespół powinien kontynuować pracę i dołączać feedback użytkowników do Backlogu Produktu

Zespół powinien przestać pracować i czekać na feedback aby działać szybciej w przypadku pilnego żądania

Zespół powinien pracować ale w krótszych Sprintach by skrócić pętle feedbacku

Zespół powinien pracować ale też dodawać pojawiające się żądania do Sprint Backlogu

Zachęć Product Ownera by podzielił się uwagami z Developerami. Pracuj z nimi wspólnie nad poprawieniem wydajności oraz rozbudowaniem DOD o parametry związane z wydajnością

Wyjaśnij Produkt Ownerowi że to w po stronie Developerów jest ocena czy parametry wydajnościowe są odpowiednie czy nie

Nie rób nic od razu. Poczekaj na Retrospektywe Sprintu bo to najlepszy moment dla Zespołu Scrumowego by porozmawiać o DOD

Zmuś Developerów by przygotowali i wykonywali lepsze testy wydajnościowe. Umieść te testy w DOD

Powinno być tylu Product Ownerów ile potrzeba. W końcu Scrum to proces empiryczny pozwalający na dużą liczbe eksperymentów

Powinien być jeden Product Owner do wszystkich produktów. Jeżeli zajdzie taka potrzeba może delegować swoje zadania.

Powinno być 4 Product Ownerów - po jednym na każdy produkt. Jeżeli zajdzie potrzeba mogą oni delegować swoje zadania.

Powinno być 4 Product Ownerów – po jednym na każdy produkt. Ale ponieważ Product to ich odpowiedzialność nie wolno im delegować swoich zadań na innych.

Prawda

Fałsz

Aktualizuje codziennie plan pracy dla Developerów.

Tworzy raporty finansowe na podstawie spędzonych godzin zgłoszonych przez Zespół Scrumowy.

Pracuje z deweloperami nad udoskonaleniem Baklogu produktu

Bierze udział w każdym Daily Scrumie, aby odpowiadać na pytania funkcjonalne dotyczące omawianych elementów Backlogu Sprintu.

Współpracuje z interesariuszami, społecznościami użytkowników i ekspertami merytorycznymi.

Timeboxy pomagają, upewniając się, że Sprint nie zatrzyma się, dopóki wszystkie testy nie zostaną zakończone, a praca zostanie zweryfikowana przez PO.

Timeboxy zapewniają PO, że Deweloperzy zakończą wszystkie prace nad Backlogiem Sprintu do końca Sprintu.

Pod koniec każdego Sprintu, gdy przedział czasowy wygaśnie, dostępny jest szczegółowy raport ze wszystkimi przypadkami testowymi i wynikami testów

Timeboxy pomagają zminimalizować ryzyko, stwarzając możliwość weryfikacji założeń z wykorzystaniem informacji zwrotnych od użytkowników i rynku; umożliwiają Zespołom Scrumowym sprawdzania postępów w kierunku osiągniecia Celu Produktowego i decydowania, czy zmienić kierunek, czy wytrwać.

Scope Protector

Główny analityk biznesowy.

Twórca i kolekcjoner wymagań.

Maksymalizator wartości.

Maksymalizator wartości.

Wykres Burn-down chart

Value burn-up chart

Wykres Gantt

Jakakolwiek praktyka pokazująca trendy wykonanej i nadchodzącej pracy

Raport akceptacji ze Sprint Review

Decyzje dyrektora finansowego, dyrektora generalnego lub rady dyrektorów.

Prac technicznych i architektonicznych, które należy wykonać w pierwszej kolejności, zgodnie ze wskazaniem głównego architekta przedsiębiorstwa

Elementów, które Scrum Master zidentyfikował jako przeszkody

Nie ma wyjątków; cała organizacja musi szanować decyzje PO

Decyzji głównego menadżera programu.

Choć te praktyki nie należą do Scrum nic nie stoi na przeszkodzie by w Scrumie używać innych praktyk. Zasadniczo Zespół ulepsza wtedy proces Scrumowy

Zespół nie dostarcza incrementu w każdym Sprincie zgodnie z założonym DOD

Zespół nie będzie w stanie wykonać wielokrotnego releasu w Sprincie

DOD jest za słaby i umożliwia powstawanie dużego długu technicznego. Co za tym idzie przejrzystość Incrementu zmniejsza się

Zespół stosuje koncepcje Hardening Sprint

Liczba „obowiązkowych” elementów Backlogu Produktu dostarczonych w wydaniu

Średni koszt wydania produktu

Terminowe wykonanie prac Zespołu Scrumowego

Jak często Twoi klienci korzystają z Twojego produktu?

Wszystkie powyższe

Zainwestuj w pomysły, które mają najwyższą wartość bieżącą na następny rok.

Zainwestuj we wszystkie, ale w proporcjonalnie obniż koszty i zobacz, jak radzą sobie

Uszereguj propozycje według potencjału rynkowego (niezrealizowana wartość) i sfinansuj jak najwięcej

Funduj małe eksperymenty w celu przetestowania proponowanych pomysłów i założeń, a następnie oceń wyników.

Backlog Produktu jest szeregowany przez Właściciela Produktu.

Backlog Produktu powinien być widoczny dla Zespołu Scrumowego i interesariuszy.

Wszystkie elementy Backlogu Produktu muszą być wyrażone jako historyjki użytkownika.

Wszystkie PBI muszą zostać zidentyfikowane przed rozpoczęciem pierwszego Sprintu

Backlog Produktu reprezentuje wkład wszystkich interesariuszy i eliminuje potrzebę, aby Deweloperzy rozmawiali z interesariuszami.

Opisuje, kto będzie używał produktu i co chciałby osiągnąć.

Opisuje, w jaki sposób ludzie będą używać produktu

Opisuje, w jaki sposób produkt będzie generował dochód.

Opisuje porównanie produktu z produktami konkurencji.