Praca w Scrumie wiąże się z koniecznością wykorzystywania wszystkich opisanych w przewodniku artefaktów, wydarzeń, ról, itd. Nie można wybrać sobie niektórych rzeczy, zapominając o filarach czy wartościach i zastanawiać się dlaczego Scrum nie działa. Jednym z takich obowiązkowych elementów jest Sprint Backlog, który tuż obok Product Backlogu oraz Przyrostu stanowi artefakty frameworku. Z jego istnieniem wiążą się określone zasady i obowiązki poszczególnych ról, a także kryteria, które musi on spełniać. W poprzednim artykule mogliście znaleźć kompendium wiedzy na temat Backlogu Produktu, tym razem podobnie podejdziemy do tematu kolejnego artefaktu.
Czym jest Sprint Backlog?
Sprint Backlog, najogólniej mówiąc, jest zbiorem Product Backlog Itemów (PBI) wspólnie wybranych przez Zespół Scrumowy podczas Planowania Sprintu. Nieodłącznym elementem SB jest również plan na dostarczenie wybranych PBI i realizację Celu Sprintu. Co prawda ostateczna decyzja o liczbie elementów pobranych do Sprintu należy tylko i wyłącznie do Zespołu Deweloperskiego. Ale to PO określa kierunek, którym należy podążać. Najważniejsza jest więc komunikacja w całym zespole i rozmowa na temat tego co jest potrzebne (żeby wytwarzany Przyrost był jak najbardziej wartościowy) i co jesteśmy w stanie zrealizować (uwzględniając nasze możliwości, dostępność zespołu, itd). Tak naprawdę to cały Zespół wspólnie określa to nad czym będzie pracował w kolejnej iteracji.
W praktyce na Planowaniu Sprintu Właściciel Produktu (PO) tłumaczy wizję biznesową, potwierdza priorytety i wskazuje dalszy kierunek rozwoju produktu. Zespół Deweloperski (DT) prognozuje jakie elementy PB będzie mógł wykonać w Sprincie. Cały Zespół Scrumowy, czyli PO, DT i SM, wspólnie pracuje nad zrozumieniem pracy będącej zakresem kolejnego Sprintu, czyli nad zawartością Sprint Backlogu. Zespół wtedy nie tylko wybiera elementy z PB ale planuje sposób ich dostarczenia i tworzy Cel Sprintu. Nie wchodząc dalej w szczegóły całego przebiegu Planowania Sprintu przejdźmy do ustalania i definicji celu.
Cel Sprintu
W przewodniku, możecie znaleźć taki fragment:
W trakcie planowania Sprintu Zespół Scrumowy tworzy także Cel Sprintu. Jest to zamierzenie, które zostanie osiągnięte w ramach Sprintu poprzez implementację wybranych elementów Backlogu Produktu. Cel Sprintu pomaga Zespołowi Deweloperskiemu zrozumieć, w jakim celu będzie on tworzyć Przyrost.
Scrum Guide, 2017
Sprint Backlog i Cel Sprintu tworzą nierozerwalną całość. Ten pierwszy tak naprawdę wskazuje pracę, którą DT uznaje za konieczną do realizacji tego drugiego. Jego ideą jest nakierowanie Zespołu do jeszcze większej współpracy. Tak żeby wspólnie pracowali nad wartością dla produktu, a nie nad odrębnymi inicjatywami. Cel Sprintu jest tworzony wspólnie przez cały Zespół Scrumowy podczas wspomnianego już Planowania Sprintu. W praktyce sprowadza się to np. do określenia wspólnej funkcjonalności produktu, którą DT deklaruje się zrealizować. Ważne żeby cel był umieszczony w widocznym miejscu. Tak żeby każdy z członków zespołu mógł w dowolnym momencie trwania Sprintu przypomnieć sobie co jest najważniejsze w danej iteracji. To wokół niego DT skupia się nie tylko podczas codziennej pracy ale również podczas Daily Scrum. Kiedy to członkowie Zespołu Deweloperskiego zastanawiają się gdzie są z realizacją Celu Sprintu. Decydują więc o kolejnych krokach na najbliższe 24h, które pomogą im ten cel osiągnąć.
Co jeszcze zawiera Sprint Backlog?
Sam Sprint Backlog oprócz wyżej wymienionych rzeczy powinien zawierać co najmniej jedną najważniejszą hipotezę wygenerowaną przez Zespół podczas Retrospektywy Sprintu. Hipotezą nazywam usprawnienie, które Zespół Scrumowy uznał za przydatne w procesie usprawniania ich pracy. Biorąc jednak pod uwagę empiryczność frameworku, może ona się udać lub też nie. Może ulec ewolucji w zależności od rezultatów jakie realizacja tego założenia będzie przynosić. Dlatego tak ważne jest żeby znalazło się ono w Sprint Backlogu, gdzie cały Zespół może transparentnie monitorować jego realizację. Oraz na koniec Sprintu, podczas kolejnej Retrospektywy zadecydować czy uważają, że udało im się zrealizować założenia i czy chcą dalej pracować, w ten lub inny sposób, nad obszarem, który wskazali jako ten wymagający ulepszenia.
Jak efektywnie pracować ze Sprint Backlogiem?
Bardzo ważnym elementem tego pytania jest słowo “efektywnie”. Zarządzanie, tudzież praca z Sprint Backlogiem powinna być płynna i tak częsta jak to konieczne i możliwe. Wykonywanie pracy w Sprint Backlogu raz na Sprint, z pewnością nie daje nam tej efektywności i zaburza przejrzystość realizowanej pracy. W praktyce, gdy używamy takich narzędzi jak Jira do budowania Backlogu Produktu, stosunkowo łatwo przenosimy elementy z jednego backlogu do drugiego podczas Planowania Sprintu. Być może nie trudniej jest przesuwać karteczki na ścianie, jeżeli pracujemy analogowo z całym zespołem. Niezależnie od tego jakich narzędzi używamy do budowania PB, a później SB, ważne żeby wszyscy zainteresowani rozwojem produktu mieli do owych narzędzi taki sam dostęp. Zespół Deweloperski jest odpowiedzialny za SB i zarządza nim podczas trwania Sprintu. Oznacza, to, że w zależności od tego jak zarządzamy przepływem pracy, poszczególne PBI powinny być przez DT przesuwane. Transparentnie odzwierciedlany jest wtedy stopień realizacji Celu Sprintu i budowania Przyrostu.
Czy zawartość Sprint Backlogu może ulegać zmianie?
Kolejnym szalenie ważnym aspektem istnienia Sprint Backlogu jest to, że stworzony podczas Planowania Sprintu może ewoluować podczas trwania Sprintu. Jest to możliwe, a nawet konieczne dlatego, że Zespół Deweloperski deklaruje się do osiągnięcia Celu Sprintu, a nie do realizacji wszystkich wybranych PBI. Nie oznacza to jednak, że można w dowolny sposób żonglować jego zawartością.
W przypadku, gdy DT zorientuje się, że zabrakło bardzo ważnego elementu aby osiągnąć Cel Sprintu powinien taki element dodać do SB i o zaistniałej sytuacji poinformować PO. Być może takie zachowania spowodują konieczność zrezygnowania z jakiś innych PBI, które również były zaplanowane na ten Sprint, ale nie dotyczyły Celu Sprintu. Nie jest to jednak problem. Wówczas DT może, i powinien, negocjować z PO przesunięcie takiego zadania do PB z odpowiednim priorytetem, tak aby realizacja Celu nie była zagrożona. Podobna sytuacja może mieć miejsce gdy PO otrzyma informację zwrotną od użytkownika końcowego, którą uzna za konieczną do wprowadzenia tak szybko jak to możliwe. Wtedy to on może negocjować z DT zawartość SB, wciąż jednak mając na uwadze Cel Sprintu.
Sprint Backlog a Retrospektywa
Tematy poruszane na Retrospektywie mogą być dowolne. Przez “dowolne” nie mam na myśli ideologicznych dyskusji, na przykład na temat szczepionek, a rzeczy związanych z polepszeniem pracy nad produktem. Czy będą to tematy techniczne czy miękkie, nie ma jednak znaczenia. Dlatego z całego serca polecam poruszyć temat samej budowy jak i zarządzania Sprint Backlogiem na jednym ze spotkań. Pamiętajcie, że kluczem do osiągnięcia sukcesu jest odpowiednia komunikacja w każdej fazie cyklu budowania produktu. Raz ustalone flow przepływu pracy może ewoluować z czasem i dlatego warto o tym rozmawiać.
Podsumowanie
Sprint Backlog jest wiecznie żywym artefaktem Scruma. Jego zawartość może się zmieniać w trakcie trwania Sprintu, jeżeli oczywiście nie wpływa to na realizację Celu Sprintu. To Zespół Deweloperski jest odpowiedzialny za jego pielęgnację, nie powinien się więc wahać jeśli chodzi o utrzymanie porządku. W Sprint Backlogu zawsze powinno znajdować się przynajmniej jedno usprawnienie wybrane podczas Retrospektywy Sprintu. Inspekcja Sprint Backlogu powinna być ciągłym procesem, warto jednak raz na jakiś czas poruszyć temat jego przejrzystości podczas tego wydarzenia.
Sprawdź nasze ostatnie artykuły:
