Co to jest Backlog Sprintu?

Przykładowe przygotowywanie Backlogu Sprintu

Czytając artykuły w internecie, można odnieść wrażenie, że jedyny Backlog, który wart jest uwagi, to Backlog Produktu. Zdecydowanie mniej informacji można znaleźć o drugim rodzaju Backlogu w Scrumie – czyli o Backlogu Sprintu. Tymczasem sukces Sprintu w dużej mierze zależy od tego, jak przygotujemy oraz jak będziemy pracować w Backlogiem Sprintu w trakcie iteracji. Czym jest Backlog Sprintu, jak z niego korzystać oraz na co zwrócić uwagę na co dzień, dowiesz się z tego artykułu.

Backlog Sprintu: definicja

Backlog Sprintu zawiera w sobie elementy Backlogu Produktu wybrane podczas Planowania Sprintu oraz plan ich zamiany w działający produkt. Obejmuje całą pracę, którą Zespół Deweloperski uznaje za konieczną, aby osiągnąć Cel Sprintu. Powstaje podczas Planowania Sprintu i jest artefaktem, z którego Zespół Deweloperski korzysta na co dzień podczas wykonywania pracy zaplanowanej na Sprint.

Składnik pierwszy: wybrane elementy z Backlogu Produktu

Praca zaplanowana na Sprint to zwykle wybrany wycinek Backlogu Produktu, którego wykonanie pozwoli zespołowi osiągnąć Cel Sprintu. W praktyce Backlog Sprintu może składać z pracy różnego typu: historii użytkownika, zadań technicznych, błędów do naprawy, długu technicznego do spłacenia. Elementy te powinny być uporządkowane, tak aby dla zespołu było jasne, którymi zadaniami powinni zająć się w pierwszej kolejności. Warto pamiętać, że samo wybranie elementów z Backlogu Produktu i przeniesienie ich do Backlogu Sprintu, nie tworzy planu dostarczenia Sprintu.

Składnik drugi: plan dostarczenia Sprintu

Jeśli wybrane elementy do Backlogu Sprintu odpowiadają nam na pytanie “co robimy”, to plan dostarczenia Sprintu odpowiada na pytanie “jak robimy”. Zwykle przybiera on formę listy czynności do wykonania lub uzyskuję wizualną reprezentację. Kiedy myślę o planie Sprintu, do głowy przychodzą mi następujące obszary, które warto omówić w zespole:

  • Kolejność wykonywania zadań (np. od których zadań zaczynamy pracę)
  • Zależności zewnętrzne (np. od innych zespołów lub dostawców)
  • Zależności wewnętrzne (np. zależności warstwy prezentacji aplikacji od warstwy logiki biznesowej)
  • Dostępność Zespołu Deweloperskiego (np. nieobecność części zespołu ze względu na urlopy lub odbywane szkolenie)
  • Dostępne kompetencje Zespołu Deweloperskiego (np. uwzględniające znajomość zasad projektowania interfejsów użytkownika)
  • Wszelkie niejasności (np. brakujące szczegóły elementów Backlogu Produktu, które mimo wszystko nie blokują pracy)
  • Ryzyko (np. związane z zależnością od usługi zewnętrznej)

Prostą techniką, która pomaga upewnić się, że cały Zespół Deweloperski tak samo rozumie plan, jest poproszenie losowej osoby w zespole, aby na koniec jego przygotowywania opowiedziała reszcie, jak będzie przebiegać jego realizacja. Zwykle ćwiczenie to pozwala wychwycić obszary, które nie zostały dostatecznie dobrze omówione i wymagają doprecyzowania oraz dodatkowych ustaleń wewnątrz zespołu.

Widoczność Backlogu Sprintu

Backlog Sprintu powstaje podczas Planowania Sprintu i bynajmniej nie jest to ostatni raz, kiedy zespół pochyla się wspólnie nad jego analizą. Zwykle jest on wyświetlany (w przypadku narzędzi elektronicznych) lub po prostu widoczny (w przypadku analogowej implementacji, np. na ścianie w przestrzeni zespołu) co najmniej raz: podczas Codziennego Scruma. Staje się wtedy artefaktem wspomagającym przeprowadzenie inspekcji zaawansowania prac zespołu i pozwala wyłapać sytuacje, w których wizja pracy zespołu, mówiąc potocznie, “rozjeżdża się”. Niemniej, nie warto ograniczać pracy z Backlogiem Sprintu wyłącznie do Codziennego Scruma, a raczej na bieżąco szukać okazji do tego, aby plan ten był zaktualizowany i odzwierciedlał rzeczywistość.

Elastyczność Backlogu Sprintu

Backlog Sprintu to żywy artefakt, który może się zmieniać na skutek zdobywania przez Zespół Deweloperski nowej wiedzy w trakcie trwania Sprintu. Wartość z posiadania planu, który był aktualny tydzień temu, jest zerowa. Stąd warto pamiętać, że jest to artefakt, który powinien odzwierciedlać wszystkie zmiany, które mają wpływ na pracę zespołu. Praca, która okazuje się trudniejsza niż planowaliśmy, nieplanowane choroby w zespole, nieprzewidziane zależności zewnętrzne – wszystkie to może mieć wpływ na Backlog Sprintu i powinno być w nim odzwierciedlone, jak tylko zdobędziemy takie informacje. Dzięki urealnieniu planu lepiej widać co pozostaje do zrobienia w kontekście pozostałego czasu dostępnego w Sprincie. Na bazie tych informacji, Zespół Deweloperski może przeplanować Sprint tak, aby pomimo perturbacji, zrealizować zaplanowany Cel Sprintu.

Właścicielstwo Backlogu Sprintu

Właścicielem Backlogu Sprintu jest Zespół Deweloperski. Odpowiada zarówno za jego zawartość jak i formę. Jeśli w dowolnym momencie zespół uzna, że istnieje lepszy sposób realizacji Celu Sprintu niż ten, który ustalili podczas Planowania Sprintu, mogą dodać do Backlogu Sprintu nowe zadania, a te, które uznają za nieaktualne, usunąć. Sam sposób organizacji Backlogu Sprintu również pozostaje w gestii zespołu, który na skutek wprowadzania kolejnych usprawnień decyduje o jego kształcie i sposobie prezentacji.

Podsumowanie

Backlog Sprintu to ważny artefakt, który — jeśli jest dobrze przygotowany — jest dla zespołu kompasem, wskazującym kierunek działań podczas Sprintu. Nie jest to jednak kompas bezobsługowy — aby był faktycznie pomocny dla zespołu, wymaga codziennej kalibracji i nieustannego upewniania się, że poprawnie wskazuje północ.

Photo by Štefan Štefančík on Unsplash

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x