Ludzie (programiści, testerzy, menadżerowie produktu, …) pracujący w ramach Scrum, różnie rozumieją czym właściwie jest Backlog Sprintu. Dla jednych będzie to tylko kontener na zadania, które są aktualnie wykonywane. Dla drugich jest to zbiór zadań wraz z dostosowującym się do rzeczywistości planem działania. Dla innych może to być narządzie do monitorowania oraz kontrolowania pracy deweloperów.

Scrum Guide jasno i czytelnie opisuje czym jest Backlog Sprintu. Ale jaki fachowiec czyta instrukcje obsługi 😉 ? Czasami jednak to co jest napisane w „instrukcji” (czyt. w Scrum Guide) nie do końca jest rozumiane. A nawet jeżeli kiedyś było oczywiste, to teraz, po miesiącach walki z kolejnymi zadaniami, nie pamiętamy co to dokładnie jest. Gdybym zadał pytanie: „Czy wiecie czym jest Backlog Sprintu?”. Większość z was zapewniałaby, że doskonale wie co to jest i jak się z nim obchodzić. Czy aby na pewno?

Rzeczywistość nie jest taka oczywista jak nam się wydaje. Wiemy, że jest to jeden z trzech artefaktów Scrum przechowujący historyjki użytkownika wykonywane w Sprincie. Zwykle pod koniec Sprintu historyjki mają przekręcany status na „zrobione” i tyle. Jak już wspomniałem, dla jednych jest to tylko kontener za zadania (pewnie wykorzystywany jeszcze z przymusu – bo tak wymyślił sobie Scrum Master). Jeżeli tak jest to należałoby zapytać się Scrum Mastera, aby wytłumaczył po co to jest lub wymienić go na bardziej kompetentnego. Dla innych jest to narzędzie monitorujące pracę „programistów” i pokazujące status postępów prac lub w szczególnych przypadkach kontrolujących czynności wykonywane przez „programistów” w dowolnym momencie ich pracy  – kontrola przecież musi być! 😉

Przy okazji przypomniały mi się słowa Steve Jobsa, który powiedział:

„It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”

W kilku zdaniach określiłem czym właściwie Backlog Sprintu nie jest. Czym właściwie jest Backlog Sprintu i jak go pielęgnować przestawię poniżej.

Kilku słowach Backlog Sprintu można opisać jako rzeczywisty i aktualny obraz pracy Zespołu Deweloperskiego podczas Sprintu wraz z planem działania zespołu na najbliższy czas.

Cechy charakterystyczne Sprint Backlogu

Sprint Backlog możemy scharakteryzować poniższymi – wynikającymi ze Scrum Guide – cechami:

• Zbiór elementów wybranych do Sprintu
• Zawiera przynajmniej jedno usprawnienie zidentyfikowane na Retrospektywie
• Zawiera plan działania
• Obrazuje całą pracę Zespołu Deweloperskiego
• Jest wystarczająco dokładny aby postępy prac były zrozumiałe (przejrzysty)
• Modyfikowany podczas Sprintu przez Zespół Deweloperski
  • Dodatkowa praca jest dodawana
  • Zbędne elementy są usuwane
• Odpowiada rzeczywistości
• Jest monitorowany przez Zespół Deweloperski
• Jest żywym artefaktem podczas Sprintu

Pierwsze trzy punkty opisują zawartość Sprint Backlogu ustaloną podczas planowania Sprintu. Pozostałe obrazują sposób postępowania ze Sprint Backlogiem.

12 kroków pielęgnacji Sprint Backlog

Brak pielęgnacji lub niewystarczająca dbałość o nasze narzędzia powodują, że po czasie nie można ich używać ponieważ się dewaluują. Tak też jest ze Sprint Backlogiem. Jeżeli nie włożymy odpowiedniego wysiłku to ostatecznie narzędzie to będzie całkowicie bezużyteczne. Oto kilka prostych zasad jak pielęgnować Sprint Backlog:

1. Przed rozpoczęciem pracy nad wymaganiem zaplanujcie to co będziecie robili,
2. Pamiętaj, że plan pracy w dużej mierze odzwierciedla DoD (definicję ukończenia), ponieważ określa kryteria techniczne a nie biznesowe*,
3. Upewnij się, że plan jest wystarczająco dokładny aby był zrozumiały dla każdego (przejrzystość). Niech każdy członek Twojego zespołu wie „co w trawie piszczy”,
4. Dbaj o to, aby wymaganie zawsze miało aktualny status,
5. Rozpoczynając pracę nad konkretnym zadaniem zadbaj o aktualizację opisu oraz jego statusu,
6. Nie pozwalaj modyfikować (swojego) Sprint Backlogu przez osoby z poza zespołu deweloperskiego,
7. Jeżeli uważacie, że o czymś zapomnieliście natychmiast dodajcie właściwe zadanie,
8. Jeżeli okaże się, że jakaś praca jest zbędna, najzwyczajniej w świecie usuńcie ją,
9. Nie okłamuj siebie i zespołu – niech rzeczywistość, czyli to co robisz jest odzwierciedlona w Sprint Backlogu. Sprint Backlog ma obrazować całą pracę, która pozostała do wykonania,
10. Nie zamykaj wymagania jeżeli wszystkie zadania nie zostały jeszcze zakończone/zamknięte,
11. Nie pozostawiaj aktywnego wymagania bez znanych wam zadań do wykonania – oznacza to brak właściwego planowania pracy,
12. Pamiętaj aby na zakończenie swojej pracy zadbać o formalności
    1. Zamknij wykonane zadania,
    2. Jeżeli wartość estymaty znacznie odbiegała od realiów – zmieńcie ją,
    3. Wykonajcie wszystkie pozostałe czynności uzgodnione z zespołem,
    4. Na koniec zamknij wymaganie

Stosując wszystkie powyższe zalecenia uzyskamy najważniejszą cechę Sprint Backlogu czyli „żywy artefakt” Scrum-u. O to właściwie walczmy, aby nasz Sprint Backlog żył! Z drugiej strony, jeżeli stwierdzimy ten fakt. Będzie to oznaczało, że cały nasz wkładany wysiłek jest właściwy i już przynosi efekty w postaci efektywnej pracy oraz właściwego kierunku rozwoju Twojego doświadczenia.

Nie powinieneś jednak zasypywać gruszek w popiele. Stagnacja jest naszym największym wrogiem. Jeżeli doznajesz przyjemnego poczucia, że wszystko samo się kręci i tak będzie już zawsze. Możesz być pewny, że niedługo „znajdziesz się poza burtą statku, który dalej popłynie bez Ciebie”!

Definicja Backlogu Sprintu – Scrum Guide 11.2017

„Backlog Sprintu

Backlog Sprintu to zbiór elementów Backlogu Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu. Poprzez Backlog Sprintu Zespół Deweloperski prognozuje, które funkcjonalności znajdą się w kolejnym Przyroście i jaką pracę należy wykonać, aby te funkcjonalności dostarczyć w postaci „Ukończonego” Przyrostu. 

Backlog Sprintu obrazuje całą pracę, którą Zespół Deweloperski uznaje za niezbędną do osiągnięcia Celu Sprintu. W celu zapewnienia procesu ciągłego doskonalenia się, Backlog Sprintu zawiera przynajmniej jedno istotne usprawnienie zidentyfikowane na poprzedniej Retrospektywie. 

Backlog Sprintu to plan wystarczająco szczegółowy, by postępy prac były zrozumiałe podczas Codziennego Scruma. Zespół Deweloperski modyfikuje Backlog Sprintu w czasie trwania całego Sprintu, tym samym „wyłania się” on podczas Sprintu. To wyłanianie się zachodzi w miarę jak Zespół Deweloperski realizuje plan i dowiaduje się coraz więcej na temat pracy, która jest potrzebna do osiągnięcia Celu Sprintu. 

Jeśli pojawia się potrzeba wykonania dodatkowej pracy, Zespół Deweloperski dodaje ją do Backlogu Sprintu. W miarę jak praca jest wykonywana albo kończona, aktualizowane jest oszacowanie pozostałej do wykonania pracy. Zbędne elementy planu są usuwane. Jedynie Zespół Deweloperski może zmieniać swój Backlog Sprintu w trakcie Sprintu. Backlog Sprintu jest dobrze widocznym, odpowiadającym rzeczywistości, tworzonym na bieżąco obrazem pracy, jaką Zespół Deweloperski planuje wykonać w trakcie Sprintu. Backlog Sprintu jest wyłączną własnością Zespołu Deweloperskiego.

Monitorowanie postępów Sprintu

W każdym momencie Sprintu cała pozostająca do wykonania praca z Backlogu Sprintu może zostać zsumowana. Zespół Deweloperski podsumowuje pozostałą do wykonania pracę przynajmniej raz dziennie – podczas Codziennego Scruma. Zespół Deweloperski obserwuje zmiany jej ilości każdego dnia Sprintu i na tej podstawie określa prawdopodobieństwo osiągnięcia Celu Sprintu. Poprzez codzienne monitorowanie pozostałej do wykonania pracy, Zespół Deweloperski zarządza postępami swojej pracy.”

* DoD jest kryterium technicznym określanym jako suma warunków technicznych produktu, standardów organizacji oraz norm. Kryteria biznesowe są odzwierciedlane w kryteriach akceptacyjnych wymagań