Retrospektywa to spotkanie poświęcone analizie sposobu pracy zespołu i wyborowi konkretnych usprawnień. W Scrum oficjalnym wydarzeniem jest Sprint Retrospective, czyli Retrospektywa Sprintu. Jej celem nie jest ocenianie ludzi ani ponowne omawianie wykonanych zadań, lecz znalezienie zmian, które mogą poprawić jakość i efektywność pracy.
W Scrum Retrospective kończy Sprint. Zespół analizuje między innymi współpracę, procesy, narzędzia i Definition of Done, a następnie wybiera najbardziej użyteczne usprawnienia. Najważniejsze z nich powinny być wdrażane możliwie szybko i mogą trafić do Sprint Backlogu kolejnego Sprintu. Tak definiuje cel retrospektywy aktualny Scrum Guide.
Automatyzacja może usprawnić przygotowanie danych, dokumentowanie ustaleń i pilnowanie działań po spotkaniu. Nie powinna jednak automatyzować samej rozmowy ani podejmować za zespół decyzji, co należy poprawić.
Retrospektywa – co to właściwie jest?
Retrospektywa to moment, w którym zespół przestaje wykonywać bieżącą pracę i przygląda się temu, jak pracował.
Typowe pytania brzmią:
- co pomagało nam osiągać cel,
- co nas spowalniało,
- gdzie pojawiały się blokady,
- które założenia okazały się błędne,
- co warto kontynuować,
- co powinniśmy zmienić,
- jakie jedno usprawnienie przetestujemy jako następne.
Retrospektywa nie musi dotyczyć wyłącznie zespołów wykorzystujących Scrum. Podobne spotkania można prowadzić po projekcie, wydaniu produktu, incydencie lub określonym okresie pracy.
Jeżeli jednak mówimy o retrospekcji Scrum, zasady są bardziej precyzyjne: Retrospektywa Sprintu jest jednym z formalnych wydarzeń Scrum i odbywa się w ramach każdego Sprintu. Aktualny Scrum Guide pozostaje w wersji z listopada 2020 roku.
Jaki jest cel retrospekcji Scrum?
Scrum Guide określa cel Sprint Retrospective jako planowanie sposobów zwiększenia jakości i efektywności. Zespół przygląda się poprzedniemu Sprintowi w kontekście ludzi, interakcji, procesów, narzędzi oraz Definition of Done. Analizuje również problemy, sposób ich rozwiązania i założenia, które okazały się nietrafione.
To oznacza, że dobra retrospektywa nie kończy się na tablicy pełnej karteczek.
Powinna prowadzić do zmiany.
Przykład:
Obserwacja: większość zadań trafia do testów pod koniec Sprintu.
Problem: testerzy otrzymują kilka zmian jednocześnie, przez co tworzy się kolejka.
Hipoteza: wcześniejsze przekazywanie mniejszych elementów zmniejszy spiętrzenie pracy.
Działanie: przez kolejny Sprint zespół będzie dzielić większe elementy tak, aby pierwsze zadania mogły trafiać do testowania wcześniej.
Pomiar: sprawdzamy czas oczekiwania na testy i liczbę elementów gromadzących się przed tym etapem.
To jest retrospektywa prowadząca do doskonalenia procesu.
Samo:
„Musimy lepiej współpracować”
nie jest jeszcze działaniem.
Retrospektywa Scrum a Sprint Review – to nie to samo
Te dwa wydarzenia są często mylone.
| Sprint Review | Sprint Retrospective |
|---|---|
| Koncentruje się przede wszystkim na wyniku Sprintu i produkcie | Koncentruje się na sposobie pracy |
| Scrum Team współpracuje z interesariuszami | Pracuje przede wszystkim Scrum Team |
| Omawiany jest rezultat i zmiany w otoczeniu produktu | Analizowane są procesy, współpraca, narzędzia i problemy |
| Może prowadzić do zmiany Product Backlogu | Prowadzi do usprawnień sposobu pracy |
| Jest przedostatnim wydarzeniem Sprintu | Kończy Sprint |
Według Scrum Guide Sprint Review służy inspekcji rezultatu Sprintu i ustaleniu przyszłych adaptacji produktu, natomiast Retrospective służy poprawie jakości i efektywności pracy.
Jeżeli podczas retrospektywy zespół przez godzinę analizuje, czy nowa funkcja spodoba się klientom, prawdopodobnie przechodzi na temat Sprint Review.
Jeżeli pyta, dlaczego testowanie tej funkcji rozpoczęło się dwa dni za późno — to temat na retrospektywę.
Kto uczestniczy w retrospekcji Scrum?
W Retrospektywie Sprintu uczestniczy Scrum Team, czyli:
- Product Owner,
- Scrum Master,
- Developers.
W obecnym Scrum Guide nie istnieje osobny „Development Team”. Scrum Team jest jedną jednostką bez podzespołów i hierarchii, składającą się z Product Ownera, Scrum Mastera oraz Developers.
Scrum Master często wspiera facylitację retrospektywy, ale spotkanie nie powinno należeć wyłącznie do Scrum Mastera.
Zespół powinien z czasem być w stanie wspólnie analizować swój sposób pracy i przejmować odpowiedzialność za usprawnienia.
Czy manager powinien uczestniczyć w retrospektywie?
Nie warto automatycznie zapraszać wszystkich zainteresowanych projektem.
Retrospektywa wymaga możliwości otwartej rozmowy o problemach zespołu. Jeżeli obecność osoby spoza Scrum Teamu powoduje autocenzurę albo zmienia spotkanie w raportowanie wyników, warto zastanowić się, czy jej udział rzeczywiście pomaga osiągnąć cel retrospektywy.
To nie oznacza zakazu rozmów z managerami czy innymi zespołami. Jeżeli problem wymaga zmiany organizacyjnej, po retrospektywie może być konieczne zaangażowanie odpowiednich osób.
Kiedy odbywa się Retrospektywa Sprintu i ile trwa?
Retrospektywa nie odbywa się już po zakończeniu Sprintu. W Scrum jest wydarzeniem należącym do Sprintu i go kończy.
Dla miesięcznego Sprintu Scrum Guide ustala maksymalny timebox wynoszący trzy godziny. W krótszych Sprintach wydarzenie jest zazwyczaj krótsze.
Nie oznacza to, że dwutygodniowa retrospektywa musi trwać dokładnie 90 minut.
Czas powinien wystarczyć na:
- zebranie istotnych obserwacji,
- zrozumienie problemów,
- wybór najważniejszych tematów,
- uzgodnienie konkretnych działań.
Skrócenie godzinnej retrospektywy do 20 minut nie jest sukcesem, jeżeli zespół kończy spotkanie bez żadnego użytecznego usprawnienia.
Jak przeprowadzić retrospektywę krok po kroku?
Scrum Guide określa cel wydarzenia, ale nie narzuca konkretnego szablonu prowadzenia retrospektywy. Zespół może dopasować format do sytuacji.
W praktyce dobrze działa prosty proces.
1. Sprawdź działania z poprzedniej retrospektywy
Nie zaczynaj od nowych karteczek.
Najpierw sprawdź:
- co mieliśmy zmienić,
- czy faktycznie to zrobiliśmy,
- jaki był rezultat,
- czy eksperyment należy kontynuować.
Jeżeli zespół podczas każdej retrospektywy generuje nowe pomysły, ale nigdy nie sprawdza poprzednich ustaleń, szybko przestanie traktować action items poważnie.
2. Zbierz dane o ostatnim Sprincie
Nie ograniczaj się do wspomnień uczestników.
Można wykorzystać zarówno obserwacje jakościowe, jak i dane z narzędzi:
- które zadania były zablokowane,
- ile pracy przeniesiono do kolejnego Sprintu,
- gdzie powstały kolejki,
- jak wyglądał cycle time,
- gdzie rosło WIP,
- które zadania wracały do poprawy,
- gdzie występowały problemy z Definition of Done.
Jira udostępnia między innymi Sprint Report, Control Chart i Cumulative Flow Diagram. CFD pokazuje przepływ elementów przez statusy oraz może pomóc znaleźć miejsca, w których gromadzi się praca.
Dane nie powinny jednak służyć do oceniania pojedynczych pracowników. Mają pomóc zrozumieć system pracy zespołu.
3. Zbierz perspektywę zespołu
Najprostszy format może opierać się na trzech obszarach:
Co działało?
Co nam przeszkadzało?
Co powinniśmy zmienić?
Nie trzeba stosować ciągle tego samego schematu. Miro udostępnia obecnie setki szablonów retrospektyw, w tym 4Ls oraz formaty Start/Stop/Continue.
Zmiana formatu ma sens wtedy, gdy pomaga spojrzeć na proces z innej strony. Nie warto natomiast wybierać coraz bardziej kreatywnych szablonów tylko po to, aby ukryć brak konkretnych rezultatów retro.
4. Grupuj obserwacje i szukaj przyczyn
Jeżeli pięć osób zapisze:
- review trwa za długo,
- pull requesty czekają,
- brak reviewerów,
- zmiany stoją po dwa dni,
- każdy review robi na końcu dnia,
prawdopodobnie nie mamy pięciu osobnych problemów.
Mamy jeden temat:
przepływ pracy przez code review.
Warto więc grupować podobne obserwacje, a następnie pytać o mechanizm problemu.
Nie tylko:
Co poszło źle?
ale:
Dlaczego nasz sposób pracy powoduje ten rezultat?
To przesuwa rozmowę od narzekania do analizy procesu.
5. Wybierz najważniejszy problem
Retrospektywa nie musi rozwiązać wszystkiego.
Lista dziesięciu usprawnień często kończy się tym, że żadne nie zostaje wykonane.
Znacznie bardziej praktyczne jest wybranie jednego lub kilku działań o największym potencjalnym wpływie.
Scrum Guide również wskazuje, że Scrum Team identyfikuje najbardziej pomocne zmiany, a usprawnienia o największym wpływie powinny być podejmowane możliwie szybko.
6. Zamień wniosek w konkretne działanie
Słabe action item:
„Lepiej komunikować blokery.”
Lepsze:
„Jeżeli zadanie jest zablokowane dłużej niż cztery godziny robocze, oznaczamy je statusem Blocked i automatycznie informujemy kanał zespołu.”
Albo:
„Przez następny Sprint ograniczamy WIP w kolumnie Review do trzech elementów i sprawdzamy wpływ na cycle time.”
Działanie powinno mieć:
- właściciela lub jasno określony mechanizm odpowiedzialności,
- termin albo konkretny Sprint,
- oczekiwany rezultat,
- sposób sprawdzenia, czy zadziałało.
Jakie pytania zadawać podczas retrospektywy?
Pytania powinny kierować rozmowę na proces i możliwość zmiany.
Przykłady:
O przepływ pracy
- Gdzie zadania czekały najdłużej?
- Co najczęściej blokowało zakończenie pracy?
- Czy rozpoczynaliśmy więcej pracy, niż byliśmy w stanie kończyć?
- Które przekazania między osobami lub zespołami powodowały opóźnienia?
O jakość
- Jakie problemy wykryliśmy zbyt późno?
- Co powodowało powrót zadań do poprawy?
- Czy Definition of Done pomaga nam utrzymywać jakość?
- Które testy lub kontrole można przesunąć wcześniej?
O współpracę
- Gdzie brakowało informacji?
- Które decyzje trwały zbyt długo?
- Czy odpowiedzialności były jasne?
- W jakim miejscu zależność od jednej osoby ograniczała zespół?
O automatyzację
- Jaką powtarzalną czynność wykonywaliśmy ręcznie?
- Który etap wymaga przepisywania danych między systemami?
- Jakie informacje zbieramy ręcznie przed każdym Sprintem?
- Które przypomnienia albo aktualizacje statusów można generować automatycznie?
O poprzednie usprawnienia
- Czy wykonaliśmy działanie ustalone podczas poprzedniego retro?
- Co się zmieniło?
- Czy problem rzeczywiście stał się mniejszy?
- Czy kontynuujemy eksperyment, zmieniamy go czy kończymy?
Jak automatyzacja może wspierać retrospekcje?
Najlepszym zastosowaniem automatyzacji nie jest „automatyczna retrospektywa”.
Jest nim usuwanie pracy administracyjnej wokół retrospektywy, aby zespół mógł poświęcić spotkanie na analizę i podejmowanie decyzji.
Automatyczne przygotowanie danych
Przed spotkaniem można automatycznie zebrać:
- liczbę ukończonych i przeniesionych elementów,
- cycle time,
- WIP,
- czas przebywania zadań w określonych statusach,
- liczbę blokad,
- błędy produkcyjne,
- wyniki pipeline CI/CD,
- inne metryki związane z problemem zespołu.
Jira posiada gotowe raporty obejmujące m.in. cycle time, velocity, Sprint Report i cumulative flow.
Nie trzeba kopiować tych danych ręcznie do prezentacji. Można przygotować dashboard lub link do odpowiedniego widoku.
Automatyczne tworzenie zadań po retrospektywie
Jeżeli zespół ustali:
„Dodajemy automatyczną walidację konfiguracji przed merge’em”
action item może zostać utworzony jako normalne zadanie w systemie pracy.
Dzięki temu ustalenie retrospektywy nie znika na osobnej tablicy, do której nikt nie zagląda.
Dobry przepływ może wyglądać tak:
retrospektywa → zaakceptowane działanie → zadanie → właściciel → termin → monitoring realizacji → sprawdzenie na kolejnym retro
Automatyczne przypomnienia
Proste przypomnienie może mieć większą wartość niż zaawansowany dashboard.
Przykład:
3 dni przed końcem Sprintu → sprawdź otwarte działania z poprzedniej retrospektywy → wyślij informację właścicielom
albo:
zadanie retrospektywne nadal otwarte przed kolejnym retro → pokaż je w przygotowanej agendzie
To ogranicza jeden z najczęstszych problemów retrospektyw: ustalenia są dobre, ale nikt do nich nie wraca.
Automatyczne wykrywanie sygnałów do dyskusji
Automatyzacja może również wskazywać nietypowe zjawiska.
Przykład:
- element pozostaje w statusie Review ponad ustalony czas,
- WIP przekracza przyjęty limit,
- liczba zablokowanych zadań rośnie,
- cycle time znacząco się wydłuża.
Cumulative Flow Diagram w Jira pozwala przykładowo zauważyć rozszerzające się obszary odpowiadające statusom, co może wskazywać na tworzące się wąskie gardła.
Taki sygnał nie mówi zespołowi, dlaczego problem wystąpił.
Daje natomiast dobry punkt startowy do rozmowy.
Przykład automatyzacji retrospekcji
Załóżmy, że zespół korzysta z Jira i komunikatora.
Problem powtarzający się na trzech retrospektywach:
zadania zbyt długo czekają na code review.
Zamiast ponownie zapisywać tę samą uwagę, zespół analizuje przepływ i ustala eksperyment:
- maksymalnie trzy elementy mogą jednocześnie znajdować się w Review,
- po przekroczeniu ustalonego czasu system wysyła alert,
- zadanie oznaczone jako Blocked jest automatycznie widoczne dla zespołu,
- na kolejnym retro porównywany jest cycle time.
Workflow:
zadanie → Review → pomiar czasu → przekroczenie progu → alert → reakcja zespołu → dane do kolejnej retrospektywy
Automatyzacja nie rozwiązuje problemu sama.
Pilnuje reguły i dostarcza dane, dzięki którym zespół może sprawdzić, czy jego eksperyment działa.
To znacznie lepsze zastosowanie automatyzacji niż generowanie przez system kolejnej listy „rekomendacji Agile”.
AI podczas retrospektywy – gdzie może pomóc?
AI może być użyteczne przy pracy z większą liczbą notatek.
Przykładowo Miro AI pozwala obecnie grupować sticky notes według słów kluczowych lub sentymentu oraz generować podsumowanie zaznaczonych notatek.
Może to przyspieszyć:
- grupowanie podobnych obserwacji,
- przygotowanie roboczego podsumowania,
- znalezienie powtarzających się tematów,
- analizę dużej liczby notatek z zespołów rozproszonych.
Trzeba jednak zachować wyraźną granicę.
AI może:
- grupować informacje,
- streszczać,
- przygotować strukturę,
- znaleźć powtarzające się słowa i tematy.
AI nie powinno:
- oceniać, kto jest „problemem” w zespole,
- decydować, która opinia pracownika jest słuszna,
- zastępować rozmowy o konfliktach,
- automatycznie wyciągać konsekwencji wobec osób,
- traktować analizy sentymentu jako obiektywnej diagnozy atmosfery zespołu.
Szczególną ostrożność trzeba zachować przy wrażliwym feedbacku pracowników. Jeżeli narzędzie AI ma przetwarzać zapis retrospektywy, zespół powinien wiedzieć, jakie dane są przetwarzane i w jakim celu.
Czego nie warto automatyzować?
Nie każda część retrospektywy jest dobrym kandydatem do automatyzacji.
| Warto automatyzować | Lepiej pozostawić zespołowi |
| Pobieranie metryk | Interpretację przyczyn problemu |
| Tworzenie raportów | Rozmowę o współpracy |
| Przypomnienia | Wybór priorytetów |
| Tworzenie action items | Ocenę, które działanie ma sens |
| Synchronizację zadań | Rozwiązywanie konfliktów |
| Grupowanie dużej liczby notatek | Budowanie zaufania |
| Monitoring statusu usprawnień | Decyzję, czy eksperyment się udał |
Najważniejsze elementy retrospektywy wymagają kontekstu, doświadczenia i rozmowy między ludźmi.
Jeżeli automatyzacja skróci przygotowanie danych o 15 minut, ale zmniejszy otwartość uczestników, nie poprawia retrospektywy.
Najczęstsze błędy podczas retrospekcji Scrum
Retrospektywa zamieniona w sesję narzekania
Problemy trzeba nazwać.
Ale każde ważne zagadnienie powinno ostatecznie prowadzić do pytania:
co możemy z tym zrobić?
Jeżeli problem znajduje się poza kontrolą zespołu, można ustalić sposób eskalacji albo eksperyment ograniczający jego skutki.
Brak realizacji ustaleń
To jeden z najpoważniejszych problemów.
Zespół co dwa tygodnie tworzy trzy action items.
Po pół roku ma 30 pomysłów i prawie żadnej widocznej zmiany.
Dlatego Atlassian rekomenduje dokumentowanie wyników retrospektywy i przekształcanie wniosków w działania; również szablony Miro mocno eksponują przypisywanie action items do właścicieli.
Zbyt wiele działań jednocześnie
Pięć problemów nie wymaga pięciu eksperymentów w następnym Sprincie.
Zmiana sposobu pracy również zużywa capacity zespołu.
Lepiej wdrożyć jedno usprawnienie, sprawdzić rezultat i podjąć kolejną decyzję.
Ciągle ten sam format
„Co było dobrze / źle / do poprawy?” może działać.
Po kilkudziesięciu powtórzeniach odpowiedzi często stają się jednak mechaniczne.
Warto zmieniać perspektywę: analizować przepływ, jakość, współpracę, ryzyko, zależności albo konkretny problem występujący w ostatnim Sprincie.
Retrospektywa oparta wyłącznie na odczuciach
Perspektywa ludzi jest niezbędna, ale pamięć jest selektywna.
Jeżeli zespół twierdzi:
„Review ostatnio trwa strasznie długo”
warto również spojrzeć na dane.
Może się okazać, że problem dotyczył tylko dwóch bardzo dużych zadań. Albo przeciwnie — wykres pokaże stopniowe pogarszanie się cycle time przez kilka Sprintów.
Najlepszy obraz daje połączenie:
dane ilościowe + doświadczenie zespołu + kontekst.
Retrospektywa używana do oceny ludzi
Metryki z Jira, GitHub czy systemu CI/CD mogą być przydatne do analizy procesu.
Nie powinny być wykorzystywane do tworzenia rankingów typu:
„programista A zamknął mniej ticketów niż programista B”.
Taki sposób wykorzystania danych szybko zmienia zachowanie ludzi i może zmniejszyć otwartość podczas kolejnych retrospektyw.
Retrospektywa powinna pomagać usprawniać system pracy, a nie tworzyć dodatkowy mechanizm kontroli pracowników.
Jak sprawić, żeby retrospekcja prowadziła do realnej zmiany?
Dobre retro można ocenić nie po liczbie zapisanych karteczek, ale po tym, czy zmieniło sposób pracy zespołu.
Przed kolejną retrospektywą warto więc wrócić do poprzedniego działania:
„Chcieliśmy zmniejszyć kolejkę przed review. Ograniczyliśmy WIP i ustawiliśmy automatyczny alert. Co się wydarzyło?”
Jeżeli cycle time spadł i zespół ocenia zmianę pozytywnie — można utrwalić rozwiązanie.
Jeżeli nic się nie zmieniło — trzeba sprawdzić dlaczego.
Jeżeli sytuacja się pogorszyła — eksperyment należy zmienić lub wycofać.
Wtedy retrospekcja tworzy prawdziwy cykl doskonalenia:
obserwacja → problem → hipoteza → działanie → automatyzacja tam, gdzie pomaga → pomiar → kolejna retrospektywa.
I właśnie w tym miejscu automatyzacja daje największą wartość: nie zastępuje retrospekcji Scrum, lecz pomaga zamienić jej ustalenia w działania, które można wykonać, obserwować i zweryfikować.
