Przejdź do treści

Pewien pomysł na podsumowanie sprintu

Planowanie sprintu przypomina planowanie kolejnego etapu pieszej wycieczki. Jesteśmy w punkcie A. Rano wstajemy i planujemy przebieg trasy na dzisiejszy dzień. Planujemy, że na koniec dnia chcemy znaleźć się w punkcie B. W trakcie naszej wycieczki spotykają nas różne niespodzianki – okazuje się, że mapa jest nieaktualna; że nie ma mostu, z którego chcieliśmy skorzystać; że drogę zagradza nam wysoki płot. Musimy sobie radzić z niespodziankami i wymyślać rozwiązania problemów. Finalnie, na koniec dnia rozbijamy obóz i sprawdzamy, czy jesteśmy w miejscu, do którego planowaliśmy dotrzeć. Być może tak jest. A być może jesteśmy zupełnie gdzie indziej…

Mieliśmy taki plan, ale poszliśmy inaczej…

Wykonując podsumowanie sprintu podczas Retrospektywy, przez długi czas brakowało mi jakieś sumarycznego obrazu sprintu. Większość zespołów, z którymi pracuję, używa systemu JIRA. JIRA co prawda ma raport nazwany Sprint Report, można z niego coś wyczytać – ale analiza raportu podczas spotkanie nie jest zbyt ciekawa dla członków zespołu.

Wreszcie postanowiłem napisać skrypt, który za pomocą JIRA API pobiera dane o sprincie i prezentuje zawartość sprintu w postaci jednej tabeli. Tabelka wygląda tak:

Już wkrótce na Atlassian Marketplace…

Tabela podzielona jest na cztery obszary.

Obszar PLANNED / DONE to lista zadań, które dodaliśmy do sprintu podczas planowania i które zakończyły się w trakcie trwania sprintu. Im więcej tutaj mamy – tym lepiej.

Obszar PLANNED / NOT DONE to lista zadań, które zaplanowaliśmy, ale nie zakończyły się one w terminie. Tutaj możemy zadać sobie pytanie – co się stało, że nie udało nam się zakończyć tych zadań. Były trudniejsze niż nam się wydawały? Inne zadania pochłonęły zbyt wiele czasu? Zabrakło nam jakiś informacji od innych zespołów? Przyczyn może być wiele.

Przechodzimy do prawej kolumny tabelki. NOT PLANNED / DONE to zadania, których nie planowaliśmy. Dodaliśmy je do sprintu w trakcie jego trwania. I, co więcej, też w trakcie trwania sprintu udało się nam je skończyć.

I finalnie mamy mamy obszar NOT PLANNED / NOT DONE. Dodaliśmy coś do sprintu w jego trakcie. Zamierzaliśmy to skończyć. Ale się nie udało…

Jaka jest wartość danych w tabelce? Tak naprawdę jest ona… bardzo niewielka. Fakt, iż w obszarze NOT PLANNED / DONE znajduje się jakieś zadanie, może mieć bardzo różne przyczyny. Może to oznaczać, że w trakcie sprintu zespół zaczął koncentrować się na rzeczach innych niż były zaplanowane – czyli jest to symptom pewnego problemu. Ale może to również oznaczać, że zespół pracował szybciej niż zakładał i w pewnym momencie ktoś powiedział: „hej, dobrze nam idzie, weźmy jeszcze jedno zadanie z backlogu!”. Żeby wyciągnąć wartościowe wnioski, trzeba znać kontekst tych informacji.

Dlatego najlepszym użyciem takiego podsumowania jest zaproszenia zespołu do dyskusji. Mogą być pomocne w tym np. takie pytania:

  • dlaczego nie udało nam się skończyć zadań, które były planowane?
  • jakie konsekwencje biznesowe ma nieukończenie planowanego zadania?
  • dlaczego zrealizowaliśmy zadania nieplanowane?
  • na ile sensowne było zrealizowanie trzech nieplanowanych zadań (i spędzenie nad nimi 22 godzin) zamiast pracy nad zadaniem niewykonanym?
  • jak moglibyśmy poprawić nasz proces planowania?

 

W idealnym świecie idealny sprint zakończyłby się tym, że wszystkie elementy mielibyśmy w obszarze PLANNED / DONE. Ale nasz świat nie jest idealny – zdarzają się w nim niektualne mapy i nieoczekiwane przeszkody terenowe. Zdarzają się w nim nieaktualne dokumentacje, trudne do wykrycia błędy, przegapione przypadki testowe oraz zwolnienia lekarskie. Dążenie do tego, żeby na końcu naszego sprintu mieć idealny raport, będzie miało negatywne skutki. Skupienie się na szczegółach może sprawić, że stracimy z oczu ogólny obraz. Dlatego rozmawiając o szczegółach zadań, nie możemy zapomnieć o dwóch najważniejszych pytaniach:

  • czy udało nam się osiągnąć cel tego sprintu?
  • czy Właściciel Produktu lub interesariusze są zadowoleni z przewidywalności pracy zespołu?

Bo może się okazać, że zespół ma 70-80% skuteczność w realizacji zaplanowanych zadań – ale jednocześnie klienci są bardzo zadowoleni z osiągniętego wyniku. Ale bywa i odwrotnie, wykonaliśmy wszystkie zaplanowane zadania, ale cel sprintu nie został osiągnięty.

A Ty jak podsumowujesz prace w sprincie podczas jego zakończenia?

 

4 komentarze do “Pewien pomysł na podsumowanie sprintu”

    1. Niestety nie jest – i raczej nie będzie. Napisany skrypt był mocno dopasowany do konkretnej instacji JIRY. Zrobienie z tego konfigurowalnego pluginu wykracza poza moje możliwości czasowo-kompetencyjne.

      Ale gdyby ktoś chciał zrobić taki plugin, to oddaję pomysł za darmo :-)

  1. bardzo interesujący ten skrypt, czy jest możliwość dowiedzieć się więcej
    jak zrobić coś podobnego?
    czy to jest na stronie w Confluence, czy na jakimś osobnym URL?
    Byłbym wdzięczny za wskazówki jak zabrać się do tematu.

    1. Zostało to zrobione w bardzo prosty sposób – poprzez skrypt w PHP, którzy wyciągał dane z Jiry przez API i prezentował je na osobnym URL-u.

      Mozna też pokusić się o napisanie pluginu, który jest wpięty w środek Jiry – ale to już zdecydowanie więcej roboty.

Skomentuj Tomasz Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.