Menu

Wydarzenia Scrumowe: ograniczanie czasu, planowanie sprintu, codzienne stand-upy i udoskonalanie zaległości

  • Główny
  • Inny
  • Wydarzenia Scrumowe: ograniczanie czasu, planowanie sprintu, codzienne stand-upy i udoskonalanie zaległości

scrum events time boxing

Wypróbuj Nasz Instrument Do Eliminowania Problemów

Wprowadzenie do zdarzeń Scrumowych:

We wcześniejszych samouczkach omawialiśmy Scrum i jego strukturę.

A nasz poprzedni samouczek wyjaśnił wszystko Artefakty Scruma szczegółowo.

Wiemy, kto tworzy Zespół Scrumowy i jakie różne artefakty powstają w trakcie tego procesu. Stworzyliśmy teraz mocne podstawy. Dlatego zróbmy krok do przodu w Scrumie i omówmy kluczowe wydarzenia / ceremonie, które składają się na Proces Scrumowy.

W tym samouczku postaramy się zrozumieć, co oznacza każde zdarzenie Scrumowe, jakie są jego podstawowe funkcje i jak szczegółowo je zorganizujemy.

wydarzenia scrumowe

Czego się nauczysz:

Przegląd

Podczas pracy nad projektem opartym na Scrumie, zespół scrumowy przechodzi serię Ceremonii Scruma.

Niektórzy mogą nazywać je ceremoniami lub wydarzeniami Scruma, a inni mogą je nazywać na rytuały lub spotkania. Niezależnie od używanej tutaj terminologii, cel każdego zdarzenia Scruma pozostaje ten sam. Zasadniczo każde ze zdarzeń Scruma pomaga w realizacji i monitorowaniu pracy Sprint.

Rodzaje zdarzeń Scrumowych

Typy zdarzeń Scrum

Każda ceremonia Scrum to osobista sprawa / spotkanie organizowane przez Scrum Mastera dla dedykowanych grup. Oprócz podstawowego zespołu w niektórych spotkaniach mogą uczestniczyć interesariusze, kierownicy dostaw, a nawet sam klient. Spotkania te są ograniczone czasowo i dlatego muszą zostać zakończone w określonych ramach czasowych.

Celem każdego spotkania jest zgromadzenie uczestników i umożliwienie im omówienia bieżącej pracy. Oczekuje się od każdego uczestnika skupienia się, zaangażowania i uczestnictwa.

Jest uważany za okazję do rozmowy, zbadania i odzyskania informacji zwrotnych na temat wykonanej pracy. W przeciwieństwie do zwykłych spotkań, zdarzenia Scrum są zorientowane na wyniki, ograniczone czasowo, oparte na grupie docelowej i mają określony cel dostosowany do każdego z nich.

Co to jest Time Boxing?

Timeboxing to jedna z kluczowych funkcji dołączanych do każdego zdarzenia Scrum. Oczekuje się, że uczestnicy będą świadomi i szanowali czas przeznaczony na każde z wydarzeń. Wydarzenia nie mogą zostać przedłużone, ale można je skrócić, jeśli cele spotkania zostały już osiągnięte.

Scrum Master, który jest również moderatorem wszystkich wydarzeń Scrumowych, upewnia się, że każdy rozumie znaczenie boxingu czasowego, a także przypomina im, aby skupili się na celu spotkania, aby uzyskać najlepsze wyniki i czasowe wyniki z odchyleniami.

Najlepiej, jeśli Timebox wydarzenia nie powinien być przedłużany, ale ponieważ wiemy, że Scrum nie dotyczy zasad, czas ten można wydłużyć do określonej długości, jeśli wszyscy uczestnicy się na to zgodzą.

Jak określamy ramy czasowe dla każdego zdarzenia Scrumowego?

Ramka czasowa dla zdarzeń Scrumowych jest wprost proporcjonalna do długości Sprintu. Jednak jedynym wyjątkiem od tej reguły jest Daily Standup, który ma ustalony przedział czasu wynoszący 15 minut niezależnie od długości sprintu.

Dla każdego wydarzenia istnieją standardowe ramy czasowe oparte na długości Sprintu. Jednak zespół ma swobodę decydowania o ramach czasowych tych wydarzeń w oparciu o ich wymagania.

Zrozummy więcej z tych koncepcji, omawiając szczegółowo każde zdarzenie Scrum.

Planowanie sprintu

Warunkiem wstępnym tej ceremonii jest posiadanie przez Właściciela Produktu stabilnego, uszeregowanego pod względem priorytetów Backlogu Produktu zawierającego historie użytkowników, przygotowanego przed przybyciem na spotkanie. Historie użytkowników powinny być dobrze sformułowane i wystarczająco jasne, aby zespół mógł je zrozumieć.

Właściciel produktu może zwrócić się o pomoc do Interesariuszy, Klienta, Projektanta i Scrum Mastera w celu opracowania Backlogu Produktu.

Kryteria akceptacji są obowiązkowe w historii użytkownika. Zespół jest upoważniony do odrzucenia historyjki użytkownika bez kryteriów akceptacji.

Cel, powód

Planowanie Sprintu to pierwsza ceremonia podczas rozpoczynania Sprintu. Celem spotkania Planowania Sprintu jest stworzenie Celu Sprintu, wybranie historyjek użytkowników z Backlogu Produktu do Backlogu Sprintu i ich szczegółowe omówienie.

Zespół zbiera się w sali konferencyjnej wraz z Właścicielem Produktu i Scrum Masterem, gdzie Właściciel Produktu przedstawia historie użytkowników, które należy wybrać na następny sprint.

Zespół może zadać dowolną liczbę pytań, aby dowiedzieć się więcej o historii, a właściciel produktu jest odpowiedzialny za odpowiadanie na pytania. Zespół może również zakwestionować historię ze względu na jej kompletność i przydatność.

Jeśli w historii wymagane są dodatkowe informacje, nieukończona zależność lub okaże się, że są niekompletne, zespół ma prawo odrzucić tę historię.

W końcu wątpliwości zostały rozwiane, a zespół zna dokładną ilość pracy, jaką należy wykonać, aby ukończyć historię, a następnie szacuje i przyznaje punkty historii do każdej historii użytkownika.

W podobny sposób omawia się i ocenia inne historie. Zespół wybiera teraz Historie z górnej części Backlogu Produktu z priorytetami do Backlogu Sprintu, które według nich będą w stanie zatwierdzić i ukończyć w Sprincie, biorąc pod uwagę ich przeszłą prędkość.

Szybkość jest określana na podstawie całkowitej liczby punktów fabularnych ukończonych w przeciętnym sprincie. Prędkość jest obliczana na podstawie historycznych Sprintów i uśredniania ich. Im więcej sprintów ukończymy, tym stabilniejsza jest prędkość zespołu.

Wiele drużyn używa kart Planning Poker do oszacowania historii. Najpopularniejszą techniką estymacji jest wskazywanie historii za pomocą serii Fibonacciego. Szereg Fibonacciego to ciąg liczb, w którym każda następna liczba w szeregu jest utworzona przez zsumowanie dwóch poprzednich liczb.

Seria Fibonacciego - 1, 1, 2, 3, 5, 8, 13 i tak dalej.

Historie użytkownika oszacowane powyżej 13 punktów opowieści są uważane za bardzo duże do ukończenia w jednym sprincie i dlatego są rozkładane na mniejsze logiczne historie użytkownika, które można oszacować indywidualnie.

Podczas spotkania planowania sprintu zespół utworzy również zadania w ramach historyjek użytkownika, które zostały wybrane do sprintu. Nie oczekuje się, że zespół będzie sprawdzał wszystkie historyjki użytkownika podczas planowania sprintu, ale wystarczy, aby je rozpocząć. Resztę zadań możesz wykonać podczas sprintu.

Kluczowym wynikiem spotkania Planowania Sprintu jest Cel Sprintu i Backlog Sprintu, który składa się z historyjek użytkownika, do których wykonania zobowiązał się zespół.

Spotkanie dotyczące planowania sprintu

Oprócz Historii Użytkowników, mogą istnieć inne rodzaje elementów, które mogą stać się częścią Backlogu Sprintu.

  • Kolce
  • Długi techniczne
  • Błędy

Kolce to zadania badawcze mające na celu znalezienie rozwiązania, tj. potrzeba, której potrzeba wyzwala sama historia użytkownika. Niektóre historie mogą nie być proste lub nie mają możliwości technicznych, a zatem wymagałyby większej analizy i badań wokół nich. Dlatego powstaje skok. Może również zawierać POC, jeśli zajdzie taka potrzeba.

Długi techniczne to refaktoryzacja istniejącego kodu. Często zdarzają się sytuacje, w których zespół musi przerobić kod, który został opracowany wcześniej, aby dostosować się do nowych wymagań.

Błędy w Scrumie są zwykle pominięte lub nowe wymagania, które wynikają z zaakceptowanych historyjek użytkownika, ale są istotne dla bieżących elementów pracy. Jeśli nie jest to wymaganie, może to być w rzeczywistości błąd w systemie, który został wykryty podczas poprzednich sprintów, ale nie został naprawiony i otrzymał priorytet w tym sprincie.

Uczestnicy

Wszyscy w Zespole Scrumowym uczestniczą w spotkaniu dotyczącym planowania sprintu. Do udziału w spotkaniu nie jest zapraszany nikt inny niż główny zespół.

Spotkanie Planowania Sprintu jest organizowane i wspomagane przez Scrum Mastera, ale Właściciel Produktu kradnie przedstawienie.

Time-box

Spotkanie dotyczące planowania sprintu może trwać nawet pół dnia w przypadku sprintu dwutygodniowego. Ramka czasowa spotkania Planowania Sprintu zależy bezpośrednio od długości Sprintu. Krótszy na krótki Sprint i dłuższy na długi Sprint.

Spotkanie dotyczące planowania sprintu odgrywa bardzo istotną rolę w ogólnej architekturze Scrum i bezpośrednio wpływa na opracowywany produkt. Dlatego zespół powinien poświęcić tyle czasu, ile jego zdaniem jest potrzebne, aby szczegółowo omówić wszystkie historie użytkowników i może zaproponować alternatywne ramy czasowe, które im odpowiadają.

Po ustaleniu i uzgodnieniu ram czasowych, obowiązkiem Scrum Mastera jest utrzymanie skupienia zespołu na celu i jednoczesne śledzenie czasu.

The Daily Standup

Cel, powód

Daily Standup to spotkanie, które daje możliwość zilustrowania ogólnego spojrzenia na stan zdrowia Sprintu. Jest to również platforma do dyskusji nad tym, nad czym pracują inni członkowie zespołu i czy jest coś, co przeszkadza w osiągnięciu celu Sprintu.

Podczas codziennego spotkania standup każdy członek zespołu dzieli się stanem swoich postępów w zakresie elementów pracy, nad którymi pracuje. Dzieliliby się także i szukali pomocy u innych członków zespołu, gdyby były jakieś przeszkody blokujące ich postępy.

The Daily Standup

Podczas codziennego spotkania na stojąco każdy członek zespołu przy stole odpowiada kolejno na następujące trzy kluczowe pytania:

„Co zrobiłeś od ostatniego Daily Standup Meeting?”

„Co planujesz dzisiaj zrobić?”

najlepszy darmowy program do czyszczenia komputera z systemem Windows 7

„Czy jest jakaś przeszkoda blokująca Twoją pracę?”

Pozostali członkowie zespołu powinni zwracać uwagę, gdy ktoś podziela ten status, i oferować pomoc, jeśli zajdzie taka potrzeba. Gdy ostatni członek zespołu odpowie na wszystkie trzy pytania, spotkanie kończy się na tym.

Codzienne spotkanie Standup daje ogólny obraz tego, jaki jest obecny i ogólny stan ukończenia iteracji, nad którą obecnie pracują. Scrum Master odgrywa bardzo ważną rolę w utrzymywaniu koncentracji na spotkaniu Daily Standup i ograniczeniu czasu. Jest również odpowiedzialny za usuwanie przeszkód, które uniemożliwiają zespołowi postęp w ich Historiach użytkowników.

Scrum Master musi również upewnić się, że nikt inny niż podstawowy zespół nie zadaje pytań i nie przedstawia statusu. W razie potrzeby może pozwolić na szybkie dyskusje wokół historyjek użytkownika, ale musi przez cały czas być świadomy i może w każdej chwili wkroczyć i poprosić członków zespołu o dyskusję offline.

Uczestnicy

Każdy może uczestniczyć w spotkaniu Daily Standup. Jednak obowiązkowe jest, aby główny zespół uczestniczył w spotkaniu i przedstawiał stan swojej pracy.

Każdy, kto nawet spoza zespołu jest zainteresowany wiedzą o postępach Sprintu, może uczestniczyć w Daily Standup Meeting, ale nie może przedstawiać statusu swojej pracy ani pytać członków Zespołu Deweloperskiego o ich pracę.

Tylko członkowie głównego zespołu mogą dzielić się postępami w pracy, a wszyscy inni powinni po cichu słuchać.

Spotkanie Daily Standup powinno być przeprowadzone, nawet jeśli obecny jest tylko jeden członek zespołu.

Zespół może samodzielnie przeprowadzić Daily Standup Meeting lub poprosić Scrum Mastera o jego ułatwienie.

Time-box

Jak sama nazwa wskazuje, codzienne spotkanie stojące odbywa się codziennie, a uczestnicy powinni wstać, ponieważ jest to krótkie spotkanie trwające tylko 15 minut. Chodzi o to, aby trzymać się porządku obrad i nie odbiegać od tematu, dlatego spotkanie jest krótkie. Prowadzenie spotkania pomaga również ludziom łatwo się do niego zaangażować, ponieważ zajmuje tylko 15 minut.

Codzienne spotkanie Standup jest również organizowane codziennie w tym samym czasie i w tym samym miejscu, aby zmniejszyć zamieszanie wśród uczestników i obciążenie przy codziennej rezerwacji sal konferencyjnych. Podczas spotkania zdecydowanie odradza się korzystanie z laptopów, komputerów stacjonarnych lub telefonów komórkowych.

Zespoły mogą zdecydować, kiedy odbywać się spotkanie Daily Standup i się go trzymać. Jednak normalną tendencją jest, aby spotkania były pierwsze co rano. W przypadku zespołów pracujących w różnych strefach czasowych poranna rozmowa może nie zadziałać, dlatego mogą zadzwonić po południu lub w innym miejscu, które najbardziej im odpowiada.

Scrum Master może również podzielić się ważnymi wiadomościami lub aktualizacjami na koniec spotkania z zespołem, jeśli pozwoli na to czas, ale nie może przedłużyć spotkania za wszelką cenę.

Przegląd sprintu

Cel, powód

Spotkanie przeglądowe sprintu polega na zademonstrowaniu wykonanej pracy oraz zebraniu opinii i poparcia. W niektórych miejscach spotkanie Przeglądu Sprintu jest również znane jako Demo Sprintu. Spotkanie Przeglądowe Sprintu odbywa się zwykle na koniec sprintu, ale przed spotkaniem Retrospekcyjnym Sprintu.

Wybrany przedstawiciel (e) z zespołu demonstruje aktualne elementy pracy sprintu. Zwykle programista pracujący nad historyjką użytkownika demonstruje swoją pracę i odpowiada na pytania zadawane przez kogokolwiek z publiczności.

Historie użytkowników, które są tworzone w oparciu o Definicję ukończenia, są jedynymi kandydatami do demonstracji podczas Spotkania Przeglądowego Sprintu.

Właściciel Produktu odgrywa bardzo ważną rolę podczas Spotkania Przeglądowego Sprintu. To on jest odpowiedzialny za ocenę każdej demonstrowanej historyjki użytkownika pod kątem kryteriów akceptacji i akceptację lub odrzucenie historii.

Zaakceptowane historie są następnie integrowane z Gotowym Przyrostem, który jest potencjalnie możliwym do dostarczenia produktem. Gdzie mogłaby się udać odrzucona lub nieukończona historia, dzwoni właściciel produktu. Odrzucone historie mogą stać się częścią następnego sprintu lub mogą zostać przeniesione do Backlogu Produktu, skąd zostaną ponownie nadane priorytety.

Kluczowym wynikiem spotkania Przeglądu Sprintu jest ogólny obraz daty zakończenia Projektu. Właściciel Produktu akceptuje / odrzuca historię, a zaakceptowane historie są następnie integrowane z Przyrostem (utworzonym podczas poprzednich sprintów) jako całością, aby dać lepszy obraz tego, na czym stoimy, kończąc cały produkt.

Innym kluczowym wynikiem spotkania Przegląd Sprintu jest to, że członkowie zespołu uczą się czegoś o szacowaniu. Liczba zaakceptowanych historyjek użytkownika określa liczbę punktów historii uzyskanych w sprincie.

W ten sposób, stopniowo sprint po sprincie, zespół może rozwinąć umiejętność prawidłowego oszacowania i podjęcia świadomej decyzji dotyczącej punktów fabularnych, które są możliwe do osiągnięcia.

Często obserwuje się, że takie spotkania rzucają światło na niepełne kryteria akceptacji lub pojawiające się nowe wymagania. Najlepszym sposobem poradzenia sobie z tą sytuacją jest zamknięcie historii i oznaczenie ich jako wykonanych, jeśli spełniają wszystkie Kryteria akceptacji, które zostały początkowo uzgodnione podczas spotkania planującego sprint.

Wszystko, co wykracza poza to, należy traktować jako nowe wymaganie, a właściciel produktu jest odpowiedzialny za te wymagania na przyszły sprint.

jaki jest najlepszy program do pobierania filmów z YouTube

Spotkanie przeglądowe sprintu

Uczestnicy

W Spotkaniu Przeglądowym Sprintu uczestniczą Członkowie Zespołu, w tym Scrum Master i Właściciel Produktu. Pozostałymi uczestnikami Spotkania Przeglądu Sprintu są interesariusze, kierownicy dostaw, klienci / użytkownicy końcowi lub wszyscy, którzy są zainteresowani udziałem w Przeglądzie Sprintu.

Time-box

W idealnym scenariuszu na dwutygodniowy sprint spędzamy około 2 godzin na spotkaniu Przegląd Sprintu. Może się to różnić w zależności od długości Sprintu. Dla krótszego sprintu, krótszego przeglądu sprintu, a dla dłuższego sprintu dłuższego przeglądu sprintu.

Podobnie jak inne spotkania, Scrum Master jest odpowiedzialny za utrzymanie tempa spotkania i upewnienie się, że działania (prezentowanie historii, odpowiadanie na pytania, akceptowanie historii, zanotowane informacje zwrotne itp.) Mieszczą się w określonych ramach czasowych.

Retrospektywa sprintu

Cel, powód

W Sprint Retrospective chodzi o ucieleśnienie tego, co mówi Agile - „ Regularne refleksje, jak stać się bardziej efektywnym ”. Retrospektywa sprintu daje całemu zespołowi okazję do refleksji i przemyślenia, jak przebiegał sprint i co należy zrobić, aby zaimprowizować procesy? Retrospektywa sprintu wykonywana jest na koniec każdego sprintu.

Podczas spotkania Retrospektywa Sprintu cały zespół zbiera się i omawia właśnie zakończony Sprint. Oczekuje się, że zespół będzie przejrzysty i wydawać uczciwe opinie, ale nie ma w pobliżu gier z winą.

Pamiętaj o celu spotkania, aby zrobić krok naprzód w dziedzinie improwizacji i nie utrzymywać zespołu poprzez zwiększanie napięcia między członkami.

Wszyscy w zespół ma odpowiedzieć na cztery podstawowe pytania:

Retrospektywa sprintu

Scrum Master prosi członków zespołu o zapisanie swoich punktów za każdy z kwadrantów, jak pokazano powyżej na karteczkach samoprzylepnych. W niektórych miejscach narzędzia są używane do tego samego celu.

Co poszło dobrze?

Członkowie zespołu przyznają jeden lub więcej punktów za to, co poszło dobrze w ostatnim Sprincie. Ta część może być również okazją do docenienia i uznania dla innych członków zespołu za ich dobrą pracę.

Czego się nauczyłeś?

Scrum jest uważany za okazję do nauczenia się czegoś nowego w każdym sprincie. Ten obszar kwadrantu ma na celu omówienie kluczowych wniosków i wniosków z ostatniego Sprintu.

Co nie poszło dobrze?

W tej sekcji zespół omawia problemy i przeszkody, które napotkali podczas ostatniego sprintu. Ta część spotkania jest zwykle najbardziej delikatna, ponieważ ludzie mogą poruszać kwestie, które mogą sprawić, że inni będą czuć się niekomfortowo.

Obowiązkiem Scrum Mastera jest uspokojenie atmosfery, jeśli zajdzie taka potrzeba, i nauczenie ludzi, jak podnosić swoje problemy w konstruktywny sposób, zamiast przechodzić przez rundy osobistych ataków.

Jeśli którykolwiek z członków nie czuje się komfortowo w konfrontacji z problemami przed innymi członkami zespołu, może później udać się do Scrum Mastera i omówić problemy.

Co można zrobić lepiej?

Ta część spotkania jest okazją dla wszystkich członków zespołu do omówienia wszystkich poruszonych wcześniej kwestii i znalezienia sposobów ich rozwiązania. Zapraszamy wszystkich członków zespołu do zaproponowania rozwiązań danego problemu. Następnie zespół wspólnie decyduje o najlepszych odpowiednich rozwiązaniach.

Zespół powinien również rozważyć trzymanie się rzeczy, które zostały omówione w sekcji, która poszła dobrze również w przyszłych sprintach, a idąc naprzód, te rzeczy można dodać jako integralną część procesu.

Wynikiem spotkania Retrospektywa Sprintu jest lista działań uzgodnionych przez uczestników w celu usprawnienia procesu nadchodzącego sprintu.

Uczestnicy

Cały Zespół Scrumowy, w tym Scrum Master i Właściciel Produktu. Ale w przeciwieństwie do codziennych spotkań standupowych, Scrum Master i Produkt również uczestniczą w dostarczaniu swoich danych wejściowych i punktów retrospektywnych.

Podobnie jak spotkanie Daily Standup, spotkanie Sprint Retrospective jest również ułatwione przez Scrum Mastera. Scrum Master zapewnia, że ​​każdy w zespole, w tym on sam, ma możliwość otwarcia się i wypowiedzenia zarówno pozytywów, jak i negatywów.

Zwróć uwagę, że uczestnicy spoza zespołu nie są zaproszeni na Spotkanie Retrospektywne Sprintu. Retrospektywa Sprintu jest uważana za mało osobiste i emocjonalne środowisko, które pozwala członkom zespołu bez wahania otworzyć się i omówić problemy, z którymi się zmierzyli podczas ostatniego sprintu.

Time-box

Słusznie zostało powiedziane, że wszystkie Ceremonie Scruma są ograniczone czasowo, a ich ramy czasowe zależą od długości Sprintu. Powiedziawszy to, w przypadku sprintu dwutygodniowego, idealnym rozwiązaniem jest spotkanie retrospektywne sprintu trwające 2 godziny.

Jeśli jednak spojrzymy na Retrospekcję Sprintu jako okazję do komunikowania się, retrospekcji i zaangażowania się w ulepszenia, jest bardzo uzasadnione, aby dać wystarczająco dużo czasu na spotkanie, aby uniknąć utraty ważnych punktów widzenia i spostrzeżeń.

Dlatego dobrze jest zaplanować spotkanie w czasie, ale nie należy tego robić kosztem komunikacji i postępu. Kolejnym bardzo ważnym wydarzeniem w Scrumie jest Udoskonalanie Backlogu. Poświęćmy chwilę, aby rzucić na to trochę światła.

Udoskonalanie zaległości

Backlog Refinement, nazywane również przygotowywaniem Backlogu, to spotkanie w celu omówienia historii użytkowników w Backlogu Produktu, które mogą być częścią następnego Sprintu. Podczas spotkania poświęconego poprawianiu zaległości cały zespół siedzi razem i omawia historie użytkowników, dostarczając w ten sposób swoje uwagi.

Ogólną ideą jest przygotowanie Backlogu Produktu na nadchodzący Sprint i upewnienie się, że historie użytkownika są gotowe do wyboru. Spotkanie Backlog Refinement organizowane jest podczas sprintu „n-1”, aby przygotować elementy do pobrania w sprincie „n”.

Wniosek

W ten sposób dotarliśmy do końca tego samouczka o „zdarzeniach Scruma”, z którym trzeba się zapoznać. Zdarzenia Scrumowe są zdecydowanie najważniejszym i najważniejszym tematem Serii Scrumowej.

W tym samouczku omówiliśmy wszystkie pięć zdarzeń Scrum, tj Sprint, planowanie sprintu, codzienna standup, przegląd sprintu i retrospekcja sprintu . Każde wydarzenie inne niż codzienne starcie ma regularny cykl na sprint, tj. Wykonywane raz na każdy sprint.

Zdarzenia dają wgląd w to, jak zadania są wykonywane w środowisku Scrum. Wszystkie zdarzenia Scrum to okazje do ulepszeń, adaptacji i inspekcji.

W następnej kolejności jest samouczek dotyczący „Defect Triaging”, które jest formalnym spotkaniem, podczas którego omawiane są wszystkie defekty obecnego Sprintu i poddawane ocenie, tj. Uszeregowane pod względem ważności.

POPRZEDNIA samouczek | NEXT Tutorial

rekomendowane lektury

^