Przesłanki postępu w sprint

Codziennie, o tej samej porze, na 15 minut, przed tablicą papierową, suchościeralną lub elektroniczną, w ustalonym miejscu lub za pomocą ustalonego środka komunikacji (gdy ceremonie odbywają się zdalnie,  lub zespół nie znajduje się w jednym miejscu), cały zespół scrumowy, bez wyjątków, opóźnień spotyka się tzw. daily (dokładnie daily scrum). Jest to spotkanie, które ma umożliwić wymianę zespołowi informacji o tym, czy przybliżamy się do celu sprintu, czy pojawiły się jakieś problemy, czy są zagrożenia. To także okazja do synchronizacji, podjęcia szybkich decyzji oraz ustalenia zasad pomocy czy współpracy. W czasie takiego spotkania każdy z obecnych uczestników powinien zabrać głos i zostać wysłuchanym. To moment oderwania od realizowanych prac i skupienia się w danym momencie na tym spotkaniu – w celu inspekcji prac i odpowiedniego dostosowania (adaptacji) działań. Spotkanie to odbywa się przez cały sprint od momentu jego rozpoczęcia na planowaniu sprint, aż do jego zakończenia. Samo spotkanie może być też jednym z tematów poruszanych na spotkaniu retrospektywy.

Miałem okazję uczestniczyć w spotkaniach daily, które były zróżnicowane pod względem sprawności przebiegu, liczby podejmowanych decyzji czy też zaangażowania członków zespołu. Obserwowałem także spotkania w innych zespołach, których nie byłem członkiem. Co ciekawe można podczas takiego spotkania usłyszeć różne sformułowania i wypowiedzi. Jedni się rozwodzili, inni przechodzili do sedna i w żołnierskich słowach mówili, to, co uważali za stosowne. Uczestniczyłem też w spotkaniu, w którym podczas daily, następowało przejście po blokach tematycznych, przy których każda z osób mogła się wypowiedzieć. W innych spotkaniach, każda z osób wypowiadała się po kolei, jedna po drugiej, czy to alfabetycznie czy też w ustalonej na bieżąco kolejności.

Załóżmy, że mamy 7 osobowy zespół i w ramach danego sprint, trzy wybrane spotkania daily, wyglądały jak na poniższym diagramie pod kątem użytych sformułowań i przekazanych informacji.

daily_diagram1_650px

Można zauważyć, że część sformułowań (jak nie większość) odpowiada na pytania, które „określają” formułę daily – Scrum Guide proponuje następujące pytania:

  • Co zrobiłem wczoraj, co pomogło Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone na diagramie zielonym tłem)
  • Co zrobię dzisiaj, co pomoże Zespołowi (Deweloperskiemu) przybliżyć się do osiągnięcia Celu Sprintu? (oznaczone pomarańczowym tłem)
  • Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu? (oznaczone tłem czerwonym)

Każda z osób formułując swoją wypowiedzieć zadecydowała o czym chce powiedzieć i co powinna powiedzieć – w zależności od wykonanej pracy, postępów, tego, co się wydarzyło poprzedniego dnia lub planu na kolejny dzień czy nawet dni. Można powiedzieć, że przeprowadza pewien proces decyzyjny – próba jego zobrazowania znajduje się na poniższym diagramie

Na diagramie dodałem dodatkowe wyjaśnienia, które z jednej strony uzasadniają umiejscowienie danego pytania w drzewku decyzyjnym (ang. decision tree) a z drugiej – tak myślę – wyjaśniają przyjęte założenia. Na diagramie analogicznymi kolorami zaznaczono elementy odpowiadające powyższym pytaniom ze Scrum Guida. Pierwszym pytaniem jest to o zakończenie swoich zadań, ponieważ najbardziej przybliża do realizacji celu sprintu. Kolejne pytania wskazują na postęp w realizacji przyjętych zobowiązań na sprint. Na końcu każdej ścieżki jest pytanie o urlop, które mógłbym pominąć, jednakże nieobecności, w szczególności te niezaplanowane, mogą znacznie wpłynąć na realizację zobowiązań – dlatego to zasygnalizowałem.

daily_diagram2_630px

Analizując wskazane komentarze członków zespołu, można powiedzieć, że odpowiedzi na niektóre pytania można się domyślić . Może być tak, że zespół umówił się na to, że mówi – nie mam problemów lub nie widzę zagrożeń dla realizacji zadań, gdy to jest faktem. Z tego co zaobserwowałem bardziej jest to odpowiedź w domyśle przy założeniu, że jak jest problem, to osoba, która go znalazła, go poruszy. Zespół mógł się także dowiedzieć wcześniej o problemie lub efekcie dotychczasowych prac. Uczestniczyłem też w daily, gdzie padało na koniec pytanie – czy są jakieś problemy lub zagrożenia dla realizacji prac. Przeważnie członkowie zespołu skupiają się na dwóch aspektach – co zrobili i planują robić w kolejnym dniu.

Odpowiadając sobie samemu na te pytania, co w sumie obrazuje diagram, skupiamy się na tym, co jest istotne z perspektywy celu sprintu oraz pozwala się zespołowi zmieścić w ograniczonym czasie dla tego spotkania. W szczególności, gdy informujemy o zakończeniu zadań, które się podjęło, dajemy sygnał zespołowi, że jest przestrzeń na pomoc, dodatkowe zadania lub uzgodnione działania.

Na diagramie umieściłem 2 rozdzielone pytania: o problem i o zagrożenie. Mógłbym to połączyć w jedno pytanie lub zamienić kolejność. Przyjąłem założenie, że najpierw rozwiązujemy problem, który może mieć skutek w braku realizacji danego zadania lub powiązanych. Podobnie jest z zagrożeniem, ale jest to ocena wykonującego zadania, które może się zmienić w przeciągu najbliższego dnia lub po dopytaniu przez członków zespołu, może być ograniczona przez odpowiednią pomoc, dodatkowe wyjaśnienia lub może być istotnym problemem, którym należy się pilnie zająć.

Na diagramie zaprezentowałem tylko trzy dni (opierając się na przykładowych wypowiedziach, które są zebrane z różnych dni), a biorąc pod uwagę, że sprint trwa dwa tygodnie lub dłużej, tych możliwych komentarzy i ich wariantów może wystąpić znacznie więcej i mogą wskazywać na różnorodne podejście poszczególnych członków zespołu. Jednakże idea jest wpólna – są one wynikiem refleksji nad poprzednim dniem oraz tym, co planuje się zrobić kolejnego dnia.

Zdalne ceremonie

Panująca epidemia/pandemia oraz wprowadzone ograniczenia przez władze państwowe oraz lokalne spowodowały, że wiele podmiotów gospodarczych zaczęło się zastanawiać nad swoją przyszłością, swoim modelem działalności oraz sposobem działania. Wiele firm, co można zaobserwować na ulicy, w artykułach oraz w serwisach internetowych, wprowadziło pracę zdalną. Pracownicy przebywając w domu wykonują obowiązki związane ze swoim stanowiskiem. Muszą się przestawić na inny sposób komunikacji, interakcji oraz wykorzystywane narzędzia.

Czytałem ostatnio artykuły dotyczące pracy zdalnej. Pojawiło się wiele rad o tym jak sobie radzić, jakie zasady stosować, aby było to efektywne, jak poradzić sobie z ograniczeniami oraz jakie narzędzia wybrać. Pojawiają się rozbudowane materiały jak korzystać z określonych narzędzi komunikacji i współdzielenia pracy. Rozpatrywane są także zalety i wady każdego z nich, a także aspekt bezpieczeństwa. Dlatego postanowiłem, że nie będę skupiać się na dostępnych narzędziach – odsyłam do wielu dostępnych publikacji. Chciałbym się skupić na umiejscowieniu elementów związanych z organizacją pracy zdalnej w dwóch procesach, o których pisałem ostatnio na swoim blogu, a mianowicie planowaniu sprint oraz retrespektywie sprint.

Na poniższym diagramie są zamieszczone te dwa procesy, z usunięciem obiektów dodatkowych. Zostały wzbogacone o pewne elementy wspólne oznaczone numerami wraz z ich odpowiednim umiescowieniem w procesie (wszystkie elementy dodatkowe są zaznaczone na pomarańczowo).

zdalne_ceremonie_520px

Dodane elementy wskazują 3 dodatkowe kroki w procesie, które są silnie związane z przejściem zespołu agile’owego na pracę zdalną. Poniżej, krótkie przybliżenie każdego z tych kroków.

Krok oznaczony (1): Przygotuj narzędzia
Pierwszy krok, od którego warto zacząć proces planowania sprint czy retrospektywy, to wybór narzędzia, za pomocą którego będzie przeprowadzone spotkanie. Po wyborze narzędzia trzeba przygotować odpowiednie środki, zaproszenie oraz wskazać zespołowi czy potrzebuje określonych mechanizmów, instalacji czy innych elementów. Wybór narzędzia jest uzależniony od potrzeb zespołu: czy zależy zespołowi, aby tylko się słyszeć oraz móc zaprezentować swój ekran, czy też potrzebne są szersze możliwości. Może jednak potrzebne są rozwiązania w zakresie zdalnej współpracy zespołu. Może zespół chce się przez całe spotkanie widzieć (co na przykład w przypadku retrospektywy byłoby przydatne, aby widzieć reakcje). Ten krok ma miejsce przed spotkaniem, na etapie jego przygotowania.

Krok oznaczony (2): Wdróż narzędzia
W momencie rozpoczęcia spotkania, warto wykonać weryfikację czy wszyscy słyszą dobrze (w sposób akceptowalny) pozostałych uczestników i czy nie mają problemów z wybranym narzędziem. Warto też sprawdzić czy jest możliwość wyświetlenia prezentacji czy przeprowadzenia sesji współpracy przy pomocy wybranego narzędzia. Jeżeli zespół korzysta z połączeń video, to dobrze sprawdzić czy obraz spełnia oczekiwania. Dobrą praktyką jest aby na początku spotkania także ustalić zasady wykorzystania narzędzia – na przykład mutowanie się uczestników, którzy w dany momencie nie mówią lub informowanie natychmiast o problemach. Element dodany jako pierwsza część spotkania.

Krok oznaczony (3): Zweryfikuj działanie
W trakcie spotkania, warto co jakiś czas upewniać się czy nikt nie wypadł ze spotkania lub czy nadal wszyscy słyszą w sposób akceptowalny pozostałych uczestników. Uczestnicy mogą też utwierdzać się, że każdy z uczestników widzi wykonane zmiany lub cały udostępniony ekran. W sytuacjach problemowych uczestnicy przypominają o ustalonych zasadach – prosząc na przykład o wyłączenie mikrofonu, poprawę mikrofonu czy też zmianę lokalizacji w domu, bo na przykład w tle są rozpraszające dźwięki. Ten element został umieszczony na diagramie jako ścieżka równoczesna procesu, dołączona do odpowiednich miejsc w procesie – tzw. bramka równoległa (ang. parallel gateway).

 

Start-stop-continue

Praca w grupie/zespole, działanie osoby pełniącej określoną rolę, realizowany proces, organizacja uroczystości/spotkania/warsztatów… – to tylko niektóre działania mające miejsce czy to w życiu prywatnym, czy to w życiu zawodowym. Sposób działania w każdym z tych obszarów może zostać przeanalizowany przy użyciu metody wskazanej w tytule wpisu – start-stop-continue. Metoda ta zakłada znalezienie odpowiedzi na pytania:

  • [start] co powinniśmy lub powinna zacząć robić osoba, aby osiągnąć lepszy efekt, lepiej zostać ocenionym czy też, aby uniknąć napotkanych problemów?
  • [stop] co powinniśmy lub powinna przestać robić osoba, ponieważ np. zauważamy, że nie przynosi to oczekiwanego efektu, wprowadza zamieszanie lub jest nieefektywne?
  • [continue] co powinniśmy lub powinna nadal robić osoba, ponieważ to przynosi właściwe efekty, jest dobrze oceniane i pomaga w realizacji zadań?

Metoda ta jest także często stosowana, obok innych dostępnych metod, podczas tzw. retrospektywy sprintu. Retrospektywa sprintu jest to spotkanie zespołu scrumowego. Jej celem jest analiza sposobu działania zespołu scrumowego, bazując na obserwacjach i odczuciach członków tego zespołu. Jest okazją, aby omówić co działa, co nie działa a czego nam brakuje podczas realizacji pracy zespołu. Mogą to być takie elementy jak komunikacja, podejście do problemów, dostępność product ownera czy inne elementy. Efektem powinna być propozycja zmian, działań, które można wdrożyć już od kolejnego sprintu.

Osoba, która moderuje takie spotkanie, powinna zadbać o zachowanie pewnego porządku spotkania, tak, aby każdy z uczestników miał świadomość jakie są oczekiwania, czego może się spodziewać oraz jaki rodzaj zaangażowania będzie oczekiwany. Pozwoli to także zapewnić, aby każdy z członków zespołu miał możliwość, aby się wypowiedzieć i przekazać swoje uwagi, przemyślenia czy zastrzeżenia. Inną kwestią jest czy każdy uczestnik będzie chciał z takiej możliwości skorzystać. Dlatego ważny jest odpowiedni dobór metod zbierania propozycji lub/i aktywizacji uczestników.

Uczestniczyłem w różnych spotkaniach retrospektywy i moim zdaniem każda jest inna. Miałem okazję kilkakrotnie poprowadzić takie spotkanie i to z kolei dało mi zupełnie inną perspektywę. Myśląc o tym, zacząłem się zastanawiać nad strukturą takiego spotkania. Próbą zobrazowania jest poniższy diagram procesu retrospektywy.

retrospektywa_515px

Poszczególne kroki procesu są następujące:

Zbierz zespół/zaproś uczestników.
Pierwszym etapem jest zebranie uczestników spotkania w (najlepiej, choć nie zawsze jest to możliwe) jednym miejscu i czasie. Dokładny termin i miejsce spotkania to często element umowy wewnątrz zespołu. Jednakże dobrze jest, aby ktoś przypomniał lub zachęcił zespół do udania się na takie spotkanie lub przygotowanie się do niego. Pozwoli to także uniknąć niepotrzebnych opóźnień w jego rozpoczęciu lub wymówek odnoszących się do braku wiedzy o spotkaniu lub konieczności przygotowania się.

Przedstaw planowany przebieg spotkania
Osoba prowadząca spotkanie powinna wskazać w jaki sposób będziemy pracować, jakie elementy wykorzystamy oraz jakiego typu zaangażowanie będzie potrzebne. Dobrze także jak przypomni jaki jest cel ceremonii oraz na jakie zasady umówił się zespół dla tej ceremonii.

Przeprowadź działania
Osoba prowadząca moderuje spotkanie, pilnuje czasu, zgodnie z przyjętymi i zaproponowanymi do wykorzystania metodami. Może także podsumowywać poszczególne etapy oraz dotychczas zebrane wnioski. Może zachęcać do udziału milczących uczestników spotkania. Na spotkaniu mogą wystąpić takie aktywności jak: ocena działań ustalonych na poprzednim spotkaniu, zebranie tematów na bieżące spotkanie, ocena zadowolenia zespołu, przegląd kontraktu, wyjaśnienie zauważonych problemów czy inne. Po każdym działaniu, osoba prowadząca powinna ustalić z zespołem czy przechodzimy do kolejnej części spotkania czy jeszcze poświęcamy czas na dokończenie rozpoczętego tematu.

Podsumuj spotkanie/Zbierz wnioski
Osoba prowadząca zbiera wnioski lub prosi zespół o ich podsumowanie. Zachęca zespół do wybrania tych działań, które podejmie w kolejnym sprint. Działania mogą dotyczyć szeregu elementów składających się na pracę zespołu. Mogą np. dotyczyć ograniczenia marnotrawstwa w działaniach zespołu, komunikacji, reakcji na ocenę pracy zespołu czy innych.

Zakończ spotkanie
Osoba prowadząca podczas tego kroku dziękuje za wykonaną pracę, określa gdzie będą dostępne zebrane wnioski, podsumowanie oraz materiały. W ramach tego kroku może także poprosić o ocenę spotkania  pod kątem jego efektywności, zadowolenia zespołu. Taka ocena może być przydatna dla osoby prowadzącej – może pomóc w lepszym przeprowadzeniu kolejnego spotkania lub może być podstawą do wybrania w przyszłości innych metod zbierania informacji lub/i aktywizacji uczestników.

Ceremonia ta jest bardzo ważna. Tak jak planowanie sprint o którym pisałem miesiąc temu, wskazuje kierunek tego CO i JAK robimy w zakresie rozwoju produktu w poszczególnych sprint, tak retrospektywa wskazuje kierunek rozwoju zespołu oraz pozwala na zmianę sposobu jego działania. Ceremonia ta pozwala na to, aby tak, jak to określa wskazana na wstępie metoda: [start] zacząć robić, coś czego nie robiliśmy, czego wg zespołu zabrakło; [stop] przestać robić to, co nam utrudnia efektywną pracę oraz [continue] kontynuować to, co zespół ocenił jako cenne i czego warto się trzymać. Jest to zgodne z duchem scruma, zakładającym ciągłą inspekcję prac (zastanawiamy się nad tym co robimy oraz jak działamy), przejrzystość działań (pokazujemy jak pracujemy, jakie są efekty oraz mówimy otwarcie co nie działa i co powinniśmy zmienić) oraz adaptację (wprowadzamy zmiany i dostosowujemy działania do zebranych oczekiwań).

 

Proces planowania sprintu

Na początku stycznia na LinkedIn jeden z jego użytkowników udostępnił wpis ze strony agileinstitute.pl o tytule „Czy cel sprintu w Scrumie jest opcjonalny?”. Autorem artykułu jest Aleksander Kóska i pod jego udostępnieniem rozwinęła się ciekawa dyskusja. W trakcie dyskusji wyraziłem swoje zdanie, że moim zdaniem dobrze jest, gdy ten cel sprintu jest zdefiniowany, bo wiemy wtedy do czego zespół dąży i łatwiej podejmować decyzje, gdy pojawią się wątpliwości. O tym więcej za chwilę… Swoją drogą warto zapoznać się ze wskazanym artykułem oraz z powiązanymi treściami.

Po zapoznaniu się z tą dyskusją, zacząłem się zastanawiać jak w „rzeczywistości” wygląda proces planowania sprintu oraz jak on jest powiązany z określonym celem sprintu. Specjalnie jedno ze słów w powyższym zdaniu umieściłem w cudzysłowie, ponieważ będzie to pewne spojrzenie na ten proces. A proces ten, czego mam świadomość, może wyglądać różnie w zależności od specyfiki produktu, składu zespołu, jego dojrzałości agile’owej, a także zebranego doświadczenia w trakcie dotychczas zakończonych sprintów. Zaznaczam, że jest to spojrzenie z perspektywy product ownera. Gdyby zapytać różne zespoły lub product ownerów, pewnie można byłoby zidentyfikować różnice, ale myślę, że pewne ramy pozostałyby wspólne.

Zacznę od próby zobrazowania tego procesu na diagramie. Następnie spróbuję go przybliżyć. Do zobrazowania procesu użyłem notacji BPMN (pokolorowanej w specjalny sposób), której staram się używać, gdy próbuję graficznie przedstawić diagramy i koncepcje omawiane we wpisach na tym blogu.

planowanie_sprint2_470px

Na diagramie zostały umieszczone następujące kroki:
1) Określ cel sprintu
Choćby wstępnie, product owner powinien określić czy w kolejnym sprint zespół ma się skupić na dalszym rozwoju funkcjonalności, dodaniu nowej funkcjonalności, likwidacji długu technologicznego, poprawie błędów, dokończeniu zadań z bieżącego sprintu lub zmianie funkcjonalności po zebranych uwagach np. z pilotażu. Możliwości jest wiele, zależy to od produktu, etapu jego rozwoju oraz ustalonego wcześniej planu działań. Product owner określając cel sprintu kieruje się wizją produktu, do której dąży. Przygotowanie sprintu oraz sama ceremonia planowania odbywa się w odpowiednim momencie czasu (dlatego zastosowałem na starcie procesu zdarzenie start event – timer).
2) Wybierz elementy z backlog
Product owner może wybrać wstępną listę elementów, którymi powinien się zespół zająć w następnym sprint. Elementy wynikają z przyjętego celu sprintu oraz priorytetów w ramach backlogu (wejście do kroku procesu oznaczone za pomocą asocjacji na diagramie). Zadania powinny być już wycenione na refinement (polecam wpis na blogu agile247.pl na temat tej ceremonii). Podczas ich wyboru uwzględnia prędkość (ang. velocity – odsyłam do szczegółowej informacji na scrum.org) oraz możliwości (ang. capacity – odsyłam do szczegółowej informacji na scrum,org) zespołu (kolejne wejścia do tego kroku, które oznaczyłem na diagramie – są to elementy wykorzystywane podczas realizacji kroku). Efektem jest wstępna wersja sprint backlog (wyjście z kroku procesu).
3) Omów elementy z zespołem
Na ceremonii planowania, wstępny sprint backlog omawiany jest z zespołem, wyjaśniane są wątpliwości (jeśli się pojawią). Często pojawia się dyskusja o tym, czy zadania są możliwe do wykonania, czy jednak nie powinny być wykonane inne zadania – bazując na doświadczeniach wcześniejszych sprintów i tym, co się wydarzyło od momentu wyceny i omówienia danego zadania podczas refinement). Product owner powinien także omówić jak dane zadanie, które wybrał w poprzednim kroku, przyczynia się do realizacji celu sprintu, który także powinien przedstawić. Zespół z kolei patrząc na proponowany cel sprintu może zaproponować inne zadania, które jego zdaniem przyczynią się do realizacji celu.
4) Zaktualizuj elementy
Jeżeli to jest konieczne elementy sprint backlog są aktualizowane i wyceniane ponownie. Podczas tego kroku mogą się pojawić dodatkowe zadania, nowe lub wzięte z backlog lub mogą zostać jakieś zadania „zrzucone” do backlog. W tym kroku może także nastąpić wstępne przypisanie opiekunów elementów (wyjście z kroku) – na przykład zespół może określić, którymi zadaniami zajmie się w pierwszej kolejności i kto z zespołu podejmuje jakie kroki. Poszczególni członkowie zespołu sami wskazują, które zadania zamierzają zrealizować. Efektem jest zaktualizowany sprint backlog.
5) Potwierdź kompletność elementów
Krok, którego celem jest ostateczne potwierdzenie czy cały zespół wie i rozumie co jest do zrobienia, do czego dąży zespół (wskazane poprzez cel sprintu), jaki jest wstępny plan na realizację zadań oraz tego, że wszystkie konieczne zmiany w sprint backlog zostały wykonane.
6) Uruchom sprint
W tym momencie powstaje pewien rodzaj umowy między zespołem a product ownerem. Pozwala ona zespołowi skupić się na wykonywaniu zaplanowanych prac. Formalne uruchomienie sprintu następuje przeważnie w narzędziu wspierającym pracę zespołu, monitorowanie postępów, dokumentowanie działań. Takie narzędzie może także wspierać liczenie prędkości zespołu.

Powyższy proces jest ważnym elementem pracy w zespole agile’owym. Planowanie to ceremonia, która decyduje w dużym stopniu o tym jak dużymi krokami rozwija się produkt. Jeżeli capacity zespołu lub jego prędkość spada, zespół w porozumieniu z product ownerem podejmie na kolejny sprint mniejsze zobowiązanie. Efektem może być późniejsze dostarczenie oczekiwanej funkcjonalności dla klienta. Może także wystąpić sytuacja, gdy konieczne będzie ograniczenie wymagań odnośnie produktu.

Jak widać cel sprintu przewija się na każdym kroku tego procesu planowania. Pomaga decydować o tym, co powinno zostać podjęte w danej iteracji a co porzucone. Bez niego będzie o wiele trudniej. Planowanie jako czynność biznesowa, zgodnie z jej definicją, zakłada silną korelację między celem oraz sposobem dojścia do niego.

W definicji zawartej w business dictionary mamy zapis: „Podstawowa funkcja zarządzania obejmująca jeden lub wiele planów do osiągnięcia optymalnego połączenia potrzeb [czyli wymagań zapisanych w backlog i planie rozwoju produktu] z dostępnymi zasobami [capacity zespołu, jego umiejętności]. Proces planowania obejmuje: (1) identyfikację celów do osiągnięcia; (2) definiuje strategię do ich osiągnięcia; (3) tworzy lub organizuje niezbędne środki [omawiane podczas planowania] (4) wdraża, prowadzi i monitoruje kroki z zachowaniem odpowiedniej sekwencji [codzienne daily pozwala na weryfikację postępu prac, identyfikację problemów]”. W nawiasach kwadratowych umieściłem komentarze odwołujące się do treści poruszonych powyżej podczas opisu procesu planowania w agile.

Myślę, że zdefiniowanie celu dla sprintu tworzy całość z ceremonią oraz jest spójne z rozumieniem procesu planowania.

Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.