Porządny Backlog Sprintu

Kontynuujemy cykl odcinków na temat porządnego wykorzystania Scruma. Backlog Sprintu jest w naszej ocenie dosyć często pomijanym artefaktem scrumowym. W zespołach, do których dołączamy, widzimy, że jest traktowany po macoszemu. Nie jest dobrze wykorzystywany w praktyce. Po przesłuchaniu tego odcinka będziesz teraz wiedzieć, po czym poznać porządny Backlog Sprintu.

Czym jest Backlog Sprintu i dlaczego jest tak ważny? Jak przeprowadzić porządny Backlog Sprintu, aby spełniał swoje zadanie. Przeczytaj nasze wskazówki oparte na pracy z zespołami zwinnymi.

Backlog Sprintu to jest jeden z artefaktów scrumowych, który bywa dosyć często pomijany lub traktowany bez należytej uwagi. Przyczyną tego może być fakt, że jest to wewnętrzne narzędzie developerów i nie jest on istotny dla interesariuszy spoza zespołu.

Backlog Sprintu składa się z trzech składowych:

• z Celu Sprintu
• z konkretnego zakresu Backlogu Produktu, 
• planu dostarczenia przyrostu. 

Dopiero kiedy występują te trzy elementy, możemy mówić o tym, że mamy Backlog Sprintu.

Po czym poznać porządny Backlog Sprintu?

Przede wszystkim zacznijmy od tego, że w ogóle podstawą jest wykorzystywanie Backlog Sprintu, bo jak wspomnieliśmy wcześniej, nie jest to regułą. Bywa tak, że jest jakiś Backlog Produktu. Na planowaniu umawiamy się, co mniej więcej z tego Backlogu Produktu zostanie wybrane i zrealizowane. Nie powstaje  jednak ten fizyczny artefakt, czyli Backlog Sprintu, który byłby reprezentacją tego, co wybraliśmy ze Sprintu. 

Taki Backlog Sprintu pokazywałby, jaki jest cel i jaki jest konkretny plan na to, żeby konkretny Sprint zrealizować.

Może on mieć postać jakichś karteczek, czy flip-charta, a w wersji elektronicznej być przygotowany np. w jakimś narzędziu typu wirtualna tablica, jak np. Miro lub Mural.  

Druga porada jest związana z samą definicją Backlogu Sprintu i jego 3 składowych, o których wcześniej wspomnieliśmy. Wszystkie te 3 składowe muszą być przedyskutowane, czy przepracowane przez deweloperów w trakcie planowania pracy na początku Sprintu. 

Z naszego doświadczenia wiemy, że z tych 3 składowych (cel, zakres i plan) najczęściej pojawia się zakres, czyli to, co sobie wybieramy z Backlogu Produktu. Następnie pod kątem częstotliwości występuje Cel Sprintu, o którym nagraliśmy cały osobny odcinek – jest to odcinek nr 7 i zachęcamy Cię do jego wysłuchania. 

Czasem ten cel jest niedoskonały, czasem to jest kilka celi – zwanych potocznie wielocelem, jednak co najważniejsze, pojawia się. 

Natomiast najczęściej brakującym elementem jest ten konkretny plan pracy. Jest on jednak bardzo istotny, gdyż mówi on kto się, zajmie czym, kiedy, w jakiej kolejności i jakie są zależności wewnętrzne oraz zewnętrzne. Pozwala on też zobaczyć jak na ten plan, przekładają się nasze kompetencje, gdzie pojawiają się wąskie gardła. Plan zmniejsza ryzyko niepowodzenia, a z drugiej strony zwiększa szanse, na to, że Cel Sprintu zostanie osiągnięty. 

Kolejną poradą, jaką chcemy Ci przekazać, jest uwzględnienie tego, że Backlog Sprintu jest planem, który może ulec zmianie. W praktyce oznacza to to, że to, co sobie zespół planuje w ramach planowania Sprintu, jest prawdziwe przez jeden, może dwa dni. I bardzo szybko okazuje się, że jakieś zadania okazują się trochę bardziej złożone, niż myśleliśmy. Potrzeba na nie więcej czasu. Trzeba dołożyć dodatkowe zadanie lub ktoś idzie niespodziewanie na L4. Należy być na to gotowym i podchodzić do planu jako elementu elastycznego, który jest dobrym punktem startowym, ale na pewno będzie się zmieniał. 

Więcej o planowaniu sprintu posłuchasz w odcinku 13.  

Ważne jest też, aby wizualizować Backlog Sprintu. Najprościej rzecz ujmując, jest to pokazanie całej pracy realizowanej w sprincie i poukładanie jej w sposób, który pomaga ją zrozumieć. 

Mówiąc o całej pracy, mamy na myśli, żeby nie było jakiejś szarej strefy, którą można rozpatrywać na dwóch poziomach. Pierwszy przypadek jest wtedy, gdy członek zespołu wykonuje konkretną pracę, ale nie jest ona odzwierciedlona w Backlogu Sprintu. Można wówczas przyjąć, że ta osoba ma przestrzeń na inne zadania. Drugi przypadek jest wtedy, gdy Product Owner nie wie, że zespół, z którym pracuje, czy w którym pracuje, zajmuje się czymś, co nie było omówione podczas planowania Sprintu. Oba przypadki sprawiają, że zdolność produkcyjna zespołu na etapie planowania jest w pewien sposób zaburzona. To ma też później konsekwencje związane z usprawnianiem, gdyż członkowie zespołu mogą nie wiedzieć o danym elemencie pracy, który nie zostaje uwzględniony podczas szukania usprawnień w procesie.

Pamiętajmy też, aby dobierać takie sposoby wizualizacji, żeby łatwo było zrozumieć każdemu członkowi Zespołu Scrumowego, jakie zadania są na konkretnym etapie i gdzie jesteśmy względem planu.

Przykładowym sposobem wizualizacji jest wizualne zaplanowanie pracy. Patrząc na taką wizualizację, wiemy kto się czym zajmuje i na jakim to jest etapie. Widzimy nie tylko przeszłość, czyli rzeczy zrobione i stan na dzisiaj, ale widzimy też kolejne etapy, czyli jak sobie zaplanowaliśmy realizację zadań. Temat ten jest dobrze przedstawiony w artykule na portalu Agile247.

Innym rodzajem wizualizacji jest przedstawienie kto, nad czym pracuje. Można to przedstawić za pomocą awatarów czy ikon z przyporządkowanymi zadaniami. 

Kolejnym przykładem wizualizacji jest wizualizacja kładąca nacisk na status prac. To spojrzenie na całość jako na proces. Warto odejść od najprostszego układu: do zrobienia, w trakcie i zrobione, który jest mocno niedoskonałym podejściem. Zastanówcie się jakie etapy w tym procesie są dla Was istotne i które warto wyszczególnić. Można do tego wykorzystać jakąś tablicę w biurze lub narzędzie typu Jira czy Trello. Dzięki temu można odkryć, gdzie są wąskie gardła, a gdzie jest spora przestrzeń do zagospodarowania. 

Ostatnią propozycją jest wizualizowanie ryzyk, problemów czy blokerów. Dobrze to funkcjonuje zwłaszcza jeśli zespół jest w jakimś stopniu uzależniony od sąsiednich zespołów współpracujących, albo od jakiegoś eksperta, albo po prostu wewnątrz zespołu widać, że są pewne zadania, które są trochę bardziej kluczowe, czy trochę bardziej krytyczne, niż pozostałe. Można je jakoś wyróżnić kolorystycznie, oznaczyć jakąś flagą, ramką, obrazkiem lub wykrzyknikiem. Będą one bardziej przykuwały wzrok i będzie wiadomo, że albo są istotniejsze, albo obarczone większym ryzykiem.

Piątą poradą, jaką mamy w temacie porządnego Backlogu Sprintu jest używanie go przez deweloperów w codziennej pracy, zarówno w trakcie Codziennych Scrumów, jak i w trakcie Sprintu. Pozwoli to też na inspekcję wcześniej przygotowanego planu, który jak wiemy na pewno się zmieni. Będziemy mogli dokonać adaptacji planu do aktualnej sytuacji i stanu prac, tak aby zrealizować Cel Sprintu.

Chcemy jeszcze podkreślić, że Codzienny Scrum to nie jest jedyny moment w trakcie dnia, kiedy warto na ten Backlog Sprintu zaglądać. Można pod koniec dnia poprzesuwać konkretne zadania zgodnie z ich rzeczywistym stanem. Jeśli cały zespół weźmie w tym udział to, pojawiają się nowe możliwości, jak np. ktoś szybciej zakończył swoje zadanie i może pomóc innej osobie, która ma bardziej skomplikowany problem do rozwiązania.

Najgorszą sytuacją jest, gdy Backlog Sprintu zostanie zbudowany, ale potem nie jest wykorzystywany, bo np. jego przygotowanie jest narzucone odgórnie bez zrozumienia przez zespół, w jakim celu go tworzą i po co mają używać. 

Ostatnią poradą jest to, aby Backlog Sprintu odzwierciedlał potrzeby zespołu. Dlatego w toku kolejnych Retrospektyw i Sprintów korzystajmy z naszych doświadczeń i ewoluujmy własny styl prowadzenia Backlogu Sprintu. Wyciągajmy wnioski z nieudanych Sprintów i zastanawiajmy się jak pod tym kątem pomaga nam Backlog Sprintu, jak mógłby wspierać nas jeszcze bardziej, abyśmy byli jako zespół lepsi i skuteczniejsi.

Backlog Sprintu jest kopalnią pomysłów na Retrospektywę. Patrząc tylko w ten artefakt, można naprawdę mocno usprawnić proces. Mamy tam przecież zarówno Cel Sprintu, jest też dyskusja o tej prognozie zakresu, a także możemy przeanalizować, jaki mieliśmy plan i jak to ostatecznie wyszło. Można wyłapać wszelkie momenty, które są nieefektywne.

Na koniec podkreślimy, że Backlog Sprintu to jest plan, który jest tworzony przez i dla deweloperów. Deweloperów oczywiście w rozumieniu scrumowym, czyli wszystkich, którzy są w zespole. Bardzo często nasi Klienci chcieliby, żeby ich zespoły były bardziej samodzielne. Warto zacząć od tego kawałka. Warto zastanowić się, czy Backlog Sprintu faktycznie jest planem zespołowym, czy może jest tak, że jakiś lider czy Project Manager, steruje stworzeniem tego planu, przypisuje zadania i nie pozostawia przestrzeni na to, żeby zespół no tak naprawdę użył samoorganizacji, żeby taki plan przygotować.

Jeżeli zastanawiasz się, jak wesprzeć zespół w samoorganizacji, to subskrybuj nasz kanał, gdyż już w kolejnym odcinek będzie właśnie o tym, jak wspierać zespół w samoorganizacji. Jeśli generalnie chcesz unikać pułapek w Scrumie, to zachęcamy Cię do sprawdzenia książki „Labirynty Scruma”. Znajdziesz w niej ponad 150 sprawdzonych rozwiązań na najczęstsze pułapki w Scrumie z rekomendacjami, czy pomysłami na to, czego warto spróbować, żeby te problemy rozwiązać. Książka cały czas jest dostępna i w wersji papierowej i w wersji ebookowej.

Dodatkowe materiały

• Cel Sprintu
• Porządne Planowanie Sprintu
• Książka Jacka Wieczorka Labirynty Scruma

Transkrypcja podcastu „Porządny Backlog Sprintu”

Kuba: W tym odcinku poruszymy temat porządnego Backlogu Sprintu. Backlog Sprintu to jest jeden z artefaktów scrumowych, które w mojej ocenie bywa dosyć często pomijany. Gdy patrzę na zespoły, gdy dołączam do jakiejś organizacji, w której już wykorzystywany jest Scrum lub Scrum jest wykorzystywany teoretycznie lub tak powiedzmy In The Name Only, to akurat tak dosyć często zdarza mi się, że Backlog Sprintu bywa traktowany przez zespół po macoszemu. Jest sobie, żeby był, ale tak naprawdę nikt poważnie nie traktuje, lub jest, bo narzędzie nam go automatycznie wygenerowało. Ale tak naprawdę nie jest w praktyce dobrze wykorzystywany. Też Backlog Sprintu jako artefakt scrumowy bywa taki trochę mniej może oczywisty, czy mniej spektakularny. Bo to jest takie bardzo wewnętrzne, zespołowe, developerów narzędzie, które po prostu, ani nie widzą go za bardzo interesariusze. Może nie jest aż tak istotny poza zespołem. Natomiast nieprzypadkowo chcemy ten wątek poruszyć i w pewnym sensie też kontynuować cykl naszych odcinków na temat porządnego wykorzystania Scruma, ponieważ Backlog Sprintu zasługuje na swoje osobne nagranie

 Jacek: Definicyjnie patrząc na Backlog Sprintu warto zwrócić uwagę na to, że składa on się z trzech składowych. Po pierwsze składa się z Celu Sprintu. Po drugie składa się z pewnego konkretnego zakresu Backlogu Produktu, który wybraliśmy na konkretny Sprint. I trzecia rzecz, trzecia składowa to jest plan dostarczenia przyrostu. Dopiero kiedy te trzy elementy mamy, możemy mówić o tym, że mamy Backlog Sprintu.

Kuba: Zasadnicza części odcinka to nie będzie oczywiście definicja Backlogu Sprintu, tylko raczej nasze porady, jak robić to porządnie. Więc zacznijmy od pierwszej naszej porady – po czym poznać porządny Backlog Sprintu?

Jacek: Przede wszystkim po tym, że w ogóle istnieje Backlog Sprintu. Tak jak Kuba wspomniał, używamy różnych narzędzi. W sensie zespoły używają różnych narzędzi. To mogą być i narzędzia online’owe, elektroniczne i narzędzia takie nazwijmy to stacjonarne. No i jedna z sytuacji, którą spotykam bardzo często, gdy pracuję z klientami jest taka, że po prostu tego Backlog Sprintu nie ma. W sensie jest jakiś Backlog Produktu. Na planowaniu umawiamy się, że coś tam mniej więcej z tego Backlogu Produktu sobie wybierzemy i zrealizujemy. Natomiast nie powstaje ten fizyczny artefakt. Nie powstaje Backlog Sprintu, który byłby reprezentacją tego, co wybraliśmy ze Sprintu. Mówiłby nam trochę o tym, jaki jest cel. No i wyraźnie też pokazywał, jaki jest konkretny plan na to, żeby konkretny Sprint zrealizować. 

Kuba: No i jeśli ty słuchaczu lub słuchaczko Backlog Sprintu masz, to może się to wydawać absurdalne, albo niewykonalne. Bo trudno sobie wyobrazić takie dobre planowanie Sprintu, później też dobrą pracę w środku Sprintu, gdy tego Backlogu Sprintu w ogóle nie mamy. Natomiast, no niestety wiele zespołów właśnie dokładnie tak, jak Jacek to zaznaczył, zatrzymuje się na poziomie wyboru, czy takiej selekcji pewnych elementów Backlogu Produktu. Zgody, że je zrobimy i w zasadzie koniec. W sensie taka nieodpowiedzialna cisza, nic więcej już nie mamy. Jacek użyłeś słowa fizyczny. To może być w takich klasycznych, stacjonarnych zespołach, to może mieć postać jakichś karteczek, jakiegoś flip-charta, jakichś jeszcze może innych elementów, o których jeszcze trochę powiemy, jak to mogłoby wyglądać. Ale, nawet jeśli to jest zespół, który jest zupełnie zdolny, korzystający z jakichś elektronicznych narzędzi, to dla mnie nie jest wymówka, że narzędzie nie umożliwia takiego tworzenia fajnego Backlogu Sprintu. To  zawsze może być zwizualizowane dodatkowo, osobno. Na przykład w jakimś Docs’ie, albo na jakimś narzędziu do tablicy wirtualnej tak jak Miro, Mural, czy tego typu rzeczy. Więc częścią pracy w Scrumie jest tworzenie tego Backlogu Sprintu i co najwyżej, no taką odrobiną kreatywności trzeba się wykazać, jeśli w naszym zespole i w naszym zestawie narzędziowym nie jest to łatwe. 

Kuba: Druga porada na temat porządnego Backlogu Sprintu to porada trochę definicyjna. Pamiętajmy, że Backlog Sprintu ma trzy składowe. Cel sprintu, zakres pracy wybranej do pracy nad tutaj konkretnym elementem Backlogu Produktu i plan dostarczenia przyrostu. Wszystkie te trzy składowe muszą być odzwierciedlone, muszą być zawarte. Muszą być przedyskutowane, czy przepracowane przez deweloperów w trakcie planowania pracy na początku Sprintu. 

Jacek: Gdybym miał poddać ocenie, które te składowe najczęściej pojawiają się, to powiedziałbym, że najczęściej pojawia się zakres. Czyli to, co sobie wybieramy z Backlogu Produktu. Następnie najczęściej widzę jakąś formę Celu Sprintu. O Celu Sprintu wspominaliśmy. Właściwie nagraliśmy cały odcinek siódmy. Więc jeśli jest to dla Ciebie interesujący temat, to zachęcam Cię do odsłuchania tego odcinka. Ten Cel Sprintu pojawia się. Czasem on jest niedoskonały, czasem jest fajny, czasem to jest kilka celi – zwanych potocznie wielocelem. Natomiast pojawia się. Natomiast to, co najczęściej, z mojej perspektywy – jest tym brakującym elementem, to jest właśnie ten konkretny plan pracy. Czyli kto się zajmie czym, kiedy, w jakiej kolejności i jakie są zależności wewnętrzne, jakie są zależności zewnętrzne. Jak na ten plan przekładają się nasze kompetencje, adresowanie jakichś wąskich gardeł. Bardzo często kompetencje testerskie okazują się być reprezentowane w trochę mniejszym stopniu niż kompetencje deweloperskie w rozumieniu programistycznym, jeżeli mówimy o IT. No i dobry plan po prostu powinien to wszystko adresować, brać pod uwagę po to no, żeby mówiąc najprościej obniżyć ryzyko niepowodzenia, albo od drugiej strony zwiększyć szanse na to, że Cel Sprintu, czyli jakaś tam nasza biznesowa potrzeba, zostanie w ramach tego Sprintu zrealizowana. 

Kuba: À propos reklamy siódmego odcinka, to jeśli Twoim sposobem na konsumowanie naszych treści jest YouTube, to mocno zachęcamy do sprawdzenia odcinka, który będzie na pewno publikowany gdzieś tutaj u góry w prawym górnym rogu. Odcinek siódmy. Swoją drogą cieszymy się, że YouTube jest też sposobem, którym możemy do ciebie docierać. Mamy już prawie 500 subskrypcji naszego kanału. Jeśli jeszcze nie subskrybujesz, to zapraszamy, bo będzie nam na pewno miło i będzie można też zobaczyć, jak nagrywa mi się uśmiechamy się do Ciebie, a nie tylko słuchać nas na słuchawkach. 

Jacek: Kolejną poradę, którą mamy, po czym poznać porządny Backlog Sprintu, jest porada brzmiąca, Backlog Sprintu jest planem, który może ulec zmianie. Czyli to, co jest istotne tutaj, to po pierwsze obydwie części. Jest plan i to jest to, co przed chwilą mówiłem. Czyli nie tylko sobie mówimy to zadanie, to zadanie, to zadanie robimy. Tylko dodatkowo dokonujemy tej czynności planowania. Czyli zastanawiamy się, w jaki sposób konkretnie będziemy funkcjonować, żeby ta praca została zrealizowana. Natomiast ta druga część mówi nam o tym, że ten plan może ulec zmianie. Co to oznacza w praktyce? Bardzo często jest tak, że to, co sobie zespół planuje w ramach planowania Sprintu, jest prawdziwe przez jeden, może dwa dni. I bardzo szybko okazuje się, że jakieś zadania okazują się trochę bardziej złożone, niż myśleliśmy. Potrzeba na nie więcej czasu. Zespół odkrywa jakąś nową wiedzę na temat realizowanej pracy, która powoduje, że trzeba dołożyć jakieś konkretne jeszcze zadanie do Backlogu Sprintu, żeby zrealizować jakiś tam większy kawałek pracy. Ktoś niespodziewanie idzie na L4 i tak dalej. Tak więc bardzo szybko się okazuje, że ten plan w tej wersji takiej na koniec planowania Sprintu, no jest fajnym punktem startowym, ale on na pewno będzie się zmieniał. 

Kuba: I to jest coś, co można sobie dać jako punkt refleksji do swojego własnego zespołu, jak to wygląda u ciebie. Zgadzam się mocno z tym, co Jacek mówi, że te plany zazwyczaj są aktualne tylko przez chwilę. No i jeśli nasz Backlog Sprintu ma ten sam kształt, albo w zasadzie prawie ten sam kształt przez cały Sprint, to możliwe, że niestety nie odzwierciedla tej naszej porady o tym, że to jest plan, który ulega zmianie. I być może nasz Backlog Sprintu jest zbyt gruboziarnisty, czyli poziom dokładności zejścia do jakichś konkretnych atomowych czynności, czy konkretnych działań, które realizujemy, jest po prostu niewystarczający. No i tak daleko jesteśmy odsunięci od naszej pracy, że ten Backlog Sprintu zupełnie się nie rusza przez cały Sprint. Na przykład pracuje nad jednym zadaniem. Może pracuje nad jednym zadaniem, może tak naprawdę pracuje nad dziesięcioma zadaniami. Tylko nie mamy takiego zwyczaju, nie mam takiego nawyku, albo tak nawet nie myślimy o tym, że Backlog Sprintu mógłby być w miarę wiernie odzwierciedlający to, jak pracujemy. No i też może jest tak, że też nasze narzędzia, albo w ogóle nasz pomysł na Backlog Sprintu nie uwzględnia tego, że ta praca będzie się jeszcze zmieniać. Czyli tak trochę obrazowo, jeśli nasz Backlog Sprintu jest zapisany markerem na papierze, to już go będzie bardzo trudno modyfikować. No bo będziemy musieli co najwyżej może wykreślić, albo dopisywać. Jeśli nasz Backlog Sprintu to jest jakieś narzędzie, które bardzo łatwo pozwala na przesunięcie, dodanie czegoś nowego, zaktualizowane, usunięcie, to to też po prostu bardzo obrazowo pokazuje, że to wszystko żyje. I oczywiście użyłem takiego dosyć trywialnego przykładu z tym dodawaniem i usuwaniem, ale myślę, że ogólna myśl jest taka właśnie, czy nasz Backlog Sprintu żyje i czy narzędziowo mu pozwalamy na to, żeby żył. Czy zwracamy na to uwagę? I zawsze w takich momentach pojawia się w grupie na przykład szkoleniowej, albo grupę, którą wspieram taki głos, no ale też dodatkowa praca. Tylko że ja uważam, że tę dodatkową pracę, nad powiedzmy utrzymywaniem tego aktualizowanego planu – trochę przeceniamy. Czyli uważamy, że ona jest o wiele cięższa, niż w rzeczywistości jest. Bo to często jest po prostu notatka na boku, w parę sekund do zrobienia. Natomiast doceńmy, jak dużą różnicę robi to, że ten plan jest ciągle aktualny. W dowolnej chwili widzę to co jest w planach, co jest skończone, gdzie jestem. Ewentualnie też, że czegoś ktoś nie przemyślał, gdzie są koledzy, z którymi pracuje w zespole. Więc tutaj ta zaleta, czy ta korzyść z tego posiadania aktualnie aktualnego planu, ciągle aktualizowanego planu, jest bardzo duża. Bo ona może pomóc zapobiec ryzykom jakichś niepowodzeń. Podnieść prawdopodobieństwo, że uda się osiągnąć ten cel, który jest istotny dla naszego, czy to Sprintu, czy też całego produktu. 

Jacek: Jeżeli trochę więcej chcesz dowiedzieć się, czy poczytać, czy posłuchać konkretnie o planowaniu sprintu, to mamy oczywiście nagrany już odcinek na ten temat i zapraszamy Cię do odcinka numer 13. 

Kuba: Czwartą poradę w temacie Backlogu Sprintu, jaką mamy dla Ciebie w tym odcinku, to jest – wizualizuj Backlog Sprintu. Bardzo mocno powiązany z tym, co przed chwilą opowiadałem o tym aktualizowanym planie. Natomiast zaakcentuję mocniej dwie rzeczy. Dobry Backlog Sprintu pokazuje całą pracę wykonywaną w Sprincie i pokazuje ją w sposób zrozumiały. Pokazuje ją w sposób taki, który sam się czyta. Oczywiste jest, na pierwszy rzut oka już wiem, gdzie jesteśmy jako zespół. No i poszerzmy ten wątek Jacek. Cała praca i w sposób zrozumiały.

Jacek: Kiedy mówimy o całej pracy, to chodzi o to, żebyśmy nie mieli jakieś takiej szarej strefy. I to można rozpatrywać na dwóch poziomach. Pierwszy przypadek jest taki, że jest wykonywana jakaś praca przez konkretną osobę i ta praca po prostu nie jest odzwierciedlona w Backlogu Sprintu. Czyli ktoś sobie patrzy na Backlog Sprintu i widzi, że jakaś tam osoba w zespole nie ma pracy. No więc może wpaść na pomysł, że może to popracujemy razem, zróbmy coś w parze, albo ja coś zrobię, a ty to przejmiesz. Ale jest to nieprawda, bo się okaże, że ta osoba robi jakieś zadania. No tylko po prostu ta informacja nie jest transparentna dla całego zespołu. To jest pierwszy przypadek, który jest problematyczny. Drugi przypadek jest taki, kiedy być może nawet zespół wie, że taka sytuacja ma miejsce, ale na przykład Product Owner nie wie, że zespół, z którym pracuje, czy w którym pracuje, zajmuje się czymś, co nie było omówione. Czymś, co nie było na stole na moment planowania Sprintu. Tak więc oba te przypadki są problematyczne, no bo pojemność zespołu, zdolność produkcyjna zespołu, wszystkie takie aspekty, które są przydatne na etapie planowania, są w pewien sposób zaburzone. Ktoś jest samotnym żeglarzem na jakimś tam oceanie, robi jakieś zadanie, ani te inne osoby w zespole nie wiedzą, że to się dzieje, ani ta osoba najczęściej też nie kontrybuuje do pracy, która została wybrana na Sprint. Więc jakby to jest cały duży oddzielny temat, jak bardzo pracujemy zespołowo, a jak bardzo jesteśmy indywidualistami, którzy deklarują na planowaniu, że zrobią jakieś konkretne zadanie, mówiąc metaforycznie, zakładają słuchawki, kaptur na głowę i po prostu robią to zadanie. Na koniec mówią, zrobiłem, zrobiłam. Tak więc oddzielny temat. Może na oddzielny odcinek, niemniej ważne jest to, żeby ta praca, która się dzieje w trakcie Sprintu była w transparentny sposób w Backogu Spintu odzwierciedlona.

Kuba: To ma też później konsekwencje związane z usprawnianiem, czyli praca, która jest niepokazana, niewidoczna, nie ma jej w Backlogu Sprintu. Być może nawet w ogóle jej nie wiemy, jako pozostali członkowie danego Zespołu Scrumowego. Ona może być też nie uwzględniona, gdy rozważamy, co możemy poprawić w swoim procesie. I niestety to na pewno, nie jest powiedzmy błędem wszystkich zespołów, jakie widzę, ale widzę zespoły, w których część pracy jest niewidoczna. I ona też automatycznie jest traktowana jako coś, co nie dotyczy tego Scruma, mimo że to są ci sami ludzie, ten sam produkt, te same czynności wykonywane. No ale to jest poza Backlogiem, czy też poza rozwiązaniem tematu na Przeglądzie Sprintu, na też Retrospektywie. Więc tutaj weźmy sobie jakby do serca taką raczej zasadę, jeśli nad tym pracuję, no to jest częścią Backlogu Sprintu. Jeśli to jest coś, co jest nieprzyjemne, jeśli to jest coś, co wleciało jakoś z boku, może poza Product Ownerem, tak jak Jacek opowiadał, no to tym bardziej powinno być gdzieś widoczne i wręcz bić po oczach, że coś tutaj nie gra, a nie raczej być traktowane jako coś, co jest tam gdzieś boczkiem, boczkiem sobie przeszło. Ale jest jeszcze ten drugi wymiar, czyli taka wizualizacja jako coś, co się w bardzo łatwy sposób interpretuje. Czyli dobierajmy takie sposoby tej wizualizacji, żeby łatwo było zrozumieć każdemu członkowi Zespołu Scrumowego, gdzie jesteśmy, jakie zadania są, w jakimś etapie, gdzie jesteśmy względem planu. Myślę, że możemy teraz trochę przykładów tego, jakie sposoby wizualizacji widujemy w Backlogach Sprintu. To jest akurat taka powiedzmy szybka kolekcja różnych sposobów na dobre Backlogi Sprintu.

Jacek: Przykładowym sposobem wizualizacji, które ja bardzo lubię, to jest wizualizacja w szczególności z naciskiem na tę część planu. Czyli takie wizualne zaplanowanie pracy, gdzie po prostu wiemy, patrząc na konkretnie przygotowaną wizualizację, czy w wersji stacjonarnej, czy wersji online-owej, kto się czym zajmuje i na jakim to jest etapie. Widzimy też tę przyszłość, czyli jak sobie zaplanowaliśmy realizację zadań. Tak więc mamy i przeszłość, czyli rzeczy zrobione i to jest stan na dzisiaj, ale także widzimy ile nam zostało czasu. Widzimy, kto jak jest obciążony, kto jest nieobecny, jak to możemy zrobić. Ten temat pokryty jest w artykule na portalu Agile247.pl o planowaniu wizualnym. Umieścimy ten link w podsumowaniu tego odcinka.

Kuba: Innym rodzajem wizualizacji, którą też bardzo lubię i wiem, że zespoły, które ją stosują cenią ją, to po prostu jakaś forma reprezentacji, kto, nad czym pracuje. To mogą być w takim świecie fizycznym, stacjonarnym, jakieś magnesy, czy jakieś takie awatary, że kto jest odpowiedzialny za które zadanie. No w świecie wirtualnym to też daje się rozwiązać poprzez właśnie jakieś ikonki, jakieś awatary, czy wizualnie widoczne na jakiejś tablicy takie przyporządkowania zadań. Pamiętajmy, że to nie chodzi o to, że ja odpowiadam jako jedyny za to zadanie i też tutaj nie gubmy tego, czy nie nadinterpretowujmy tego, ale no fakt, że dwie, trzy, cztery osoby pracują nad jakimś zadaniem, a ktoś nad nimi nie pracuje, też daje jakąś szybką informację dla pozostałych członków zespołu, by korygować plany, by może wiedzieć do kogo się odezwać. Zwłaszcza w większym zespole. Może się okazać, że to będzie dosyć wartościowa cząstka informacji na temat tego, kto się podjął którego zadania. 

Jacek: Myślę, że jeszcze takim dodatkowym sposobem jest wizualizacja z takim akcentem bardziej na status prac. Czyli trochę mniej może czas plus ludzie, a trochę bardziej takie spojrzenie na proces. Bardzo często zespoły sobie układają ten proces według własnego uznania, startując często od takiego klasyka, czyli do zrobienia, w trakcie i zrobione. Oczywiście jest to każdy, kto trochę popracować wie, że to jest niedoskonałe podejście i warto poszukać sobie swojego procesu. Zastanowić się jakie etapy w tym procesie są dla nas istotne i które warto wyszczególnić. Tak więc, czy w wersji, w biurze, na jakiejś tablicy, czy korzystając z narzędzi takich jak na przykład Jira czy Trello, czy inne dostępne narzędzia, które pomagają ogarnąć pracę wykonywaną w Sprincie, jesteśmy w stanie sobie taką tablicę wyświetlić i też sporo informacji można z takiej tablicy wyczytać. Między innymi, jak na dłoni najczęściej jesteśmy w stanie zobaczyć, gdzie są wąskie gardła, gdzie praca się blokuje, a gdzie z kolei jest spora przestrzeń. 

Kuba: I ostatnia rzecz, którą ja bym ze swojej strony dodał na temat możliwych przykładowych wizualizacji, to jest coś, co już być może wykracza poza taką prostą definicję. To wizualizowanie jakichś ryzyk albo problemów, czy blokerów, może zależności. Fajnie to funkcjonuje, zwłaszcza jeśli zespół jest w jakimś stopniu uzależniony na przykład od sąsiednich zespołów współpracujących, albo od jakiegoś eksperta, albo po prostu wewnątrz zespołu widzi, że są pewne zadania, które są trochę bardziej kluczowe, czy trochę bardziej krytyczne, niż pozostałe. To może możemy je jakoś wyróżnić kolorystycznie, może w jakiś sposób zakodować jakąś flagą, ramką, obrazkiem, wykrzyknikiem. Żeby w toku wykorzystywania tego Backlogu Sprintu, czy w środku prac, czy w trakcie Daily, po prostu zobaczyć, czy przykuć pewną uwagę do jakichś konkretnych elementów, które są z jakiegoś powodu w uznaniu zespołu istotniejsze, czy no może bardziej zagrożone, niż pozostałe. 

Jacek: Kolejna porada odnośnie porządnego Backlogu Sprintu jest taka, żeby używać tego Backlogu Sprintu, zarówno w trakcie Codziennych Scrumów, jak i w trakcie Sprintu. Jeżeli mamy przygotowany ten plan, no to po prostu szkoda by było go nie wykorzystać. Tak jak wspominałem wcześniej, ten plan, on się zdezaktualizuje na 100 procent i tego możemy być pewni. Tak więc korzystanie na Codziennym Scrumie akurat, no to powiedzmy, że to jest sposób na dokonanie inspekcji i sprawdzenie, czy ta rzeczywistość, która nas otacza, jak ona ma się do planu. No i pozwala dokonać adaptacji, czyli zastanowić się dobrze, no to skoro rzeczywistość jest taka, a plan jest taki, no to co my z tym planem zrobimy, żeby on pomógł nam zrealizować Cel Sprintu. Więc to jest jakby jeden aspekt, ale z drugiej strony, to nie jest tak, że Codzienny Scrum, to jest jedyny moment w trakcie dnia, kiedy warto na ten Backlog Sprintu zaglądać. Moje takie dobre wspomnienia z pracy z zespołami są takie, mówię tutaj o pracy biurowej, bo to tak fajnie wizualnie było widać, że po prostu ktoś podchodził po skończeniu pracy do tablicy, przesuwał konkretne zadania. Jakaś inna osoba to kątem oka dostrzegała, więc też podchodziła, bo tam jakieś miała temat w stosunku do tego. Nagle się okazywało, że dwie, trzy, cztery osoby dokonują takiego bardzo ad hockowego przeplanowania Sprintu, po prostu na bazie tego, że ktoś jakąś pracę skończył i być może wziąłby zadanie X, ale jakaś osoba przekonuje, a może byś pomógł nam w tym, albo w tamtym. Tak więc ten Backlog Sprintu, kiedy wkładamy już ten wysiłek, żeby ten plan przygotować, żeby ten cel mieć sensowny, no to warto po prostu wykorzystać ten potencjał, który płynie z posiadania tego Backlogu Sprintu, czyli po prostu używać go i korzystać na co dzień.

Kuba: I ja tak trochę odwrócę może trochę bardziej negatywnie, że wielkim nieszczęściem jest to, jak właśnie zespół z jakiegoś powodu jednak buduje ten Backlog Sprintu. Na przykład Scrum Master namawia cały zespół, albo jest jakimś tam nawykiem, albo narzędzie w jakiś sposób bardzo pomaga lub każe. To powiedziałeś tak negatywnie. A potem po prostu to znika. W sensie nie zaglądamy w tę zakładkę, nie otwieramy tej kartki. Te kartki same odpadają, aż w końcu jest sprzątaczka sprzątanie i zupełnie nam to do niczego nie służy. To jest dosyć wyraźny objaw takiego Scruma mechanicznego, czyli wykonujemy te czynności, ale tak naprawdę nie wiemy po co. No i akurat planowanie Sprintu i tworzenie Backlogu Sprintu ma pomagać całemu zespołowi, a nie być czynnością do odhaczenia, żeby tam zadowolony był jakiś biurokrata lub mechanik od Scruma. Więc korzystajmy, używajmy, próbujmy go używać, jeśli do tej pory go nie użyliśmy. Bo to daje ciekawe sprzężenie zwrotne do naszej ostatniej porady, o której za chwilę. No jak używamy, to będziemy się starać, żeby to było dla nas użyteczne. Więc taki trochę jajko i kura. Jak nigdy nie używam, to w sumie mam to w nosie jak to wygląda. Jak będę używać, to będę o to dbać na etapie planowania i będę też dbać na etapie doskonalenia. 

Kuba: I ta ostatnia zapowiedziana porada, to jest to, że Backlog Sprintu musi odzwierciedlać potrzeby zespołu. Czyli w toku kolejnych Retrospektyw, kolejnych Sprintów, które mamy na swoim koncie, mamy jakieś doświadczenia pozytywne i negatywne. Mamy jakieś nieudane próby, mamy niedowiezione Sprinty. Wyciągajmy wnioski i zastanawiamy się też, jak pod tym względem Backlog Sprintu nam pomaga, albo jak mógłby pomagać, żebyśmy byli jako zespół lepsi. Lepiej komunikować pewne rzeczy, które są dla nas ważne. Być może lepiej odzwierciedlać pewne plany pracy. Lepiej pomagać zidentyfikować, że coś się szykuje niedobrego, wcześniej to wykryć. Więc tutaj pod tym względem, coś, co obserwuję to to, że zespoły, które długo pracują, też ewoluują ten swój Backlog Sprintu pod swoje indywidualne potrzeby. I to jest bardzo zawsze ciekawa historia, jak wyglądał kiedyś nasz Backlog Sprintu, jak wygląda dzisiaj i o czym jeszcze myślimy, że moglibyśmy go lekko podrasować, czy lekko zewoluować. Dosłownie czasami o detale, ale to są takie nasze własne detale.

Jacek: No Backlog Sprintu to jest kopalnia pomysłów na Retrospektywę. Patrząc tylko w ten artefakt, moim zdaniem można naprawdę mocno usprawnić proces. No bo mamy tam Cel Sprintu, gdzie jest jakby spore pole do usprawnienia. Jest ta dyskusja o tej prognozie zakresu. No i przede wszystkim też możemy sobie tam zahaczyć o to, jaki mieliśmy plan, jak to wyszło. Wyłapywać wszelkie momenty, które są  nieefektywne. Gdzieś tam za długo czekamy. Jakaś praca zbyt długo czeka na podjęcie. Więc być może momentami to będzie bardziej dyskusja taka z poziomu Lean Software Development, albo może będziemy zaznaczać o Kanbana. Natomiast tak, to jest właściwy kierunek i też jakby czerpania inspiracji z innych miejsc niż tylko Scrum. Kiedy spojrzymy na Backlog Produktu, jest kierunkiem, który osobiście zdecydowanie polecam. Warto na koniec dodać czy może przypomnieć, że Backlog Sprintu to jest plan, który jest tworzony przez deweloperów i dla deweloperów. Deweloperów oczywiście w rozumieniu scrumowym, czyli wszyscy, którzy są w zespole. Bardzo często Klienci chcieliby – nasi klienci, żeby ich zespoły były bardziej samodzielne. Warto zacząć od tego kawałka. Warto zastanowić się, czy Backlog Sprintu faktycznie jest planem zespołowym, czy może jest tak, że ktoś z tylnego siedzenia, jakieś lider czy Project Manager, steruje stworzeniem tego planu. Przypisuje zadania. Nie zostawia przestrzeni na to, żeby zespół no tak naprawdę użył samoorganizacji, żeby taki plan przygotować. Jeżeli zastanawiasz się, co z tym zrobić, jak generalnie wesprzeć zespół w samoorganizacji, to mamy dobrą wiadomość. Kolejny odcinek będzie właśnie o tym, jak wspierać zespół w samoorganizacji. Między innymi na przykładzie tego, o czym rozmawialiśmy dzisiaj, czyli samodzielnego planowania pracy, ale nie tylko. Tak więc bardzo treściwy i wartościowy odcinek szykuje się w naszej kolejce.

Kuba: A notatki do tego odcinka, artykuł na jego bazie, transkrypcję naszej rozmowy, zapis wideo, który rekomendowałem też, znajdziesz na stronie porzadnyagile.pl/71. Przypomnę też, że polecam odcinek na temat Celu Sprintu. Był to odcinek siódmy oraz na temat Planowania Sprintu. To odcinek 13. 

Jacek: Dzisiejszy odcinek był dosyć mocno o tym, jak dobrze zrobić Backlog Sprintu. Ja chciałbym przypomnieć, że jeżeli generalnie chcesz unikać pułapek w Scrumie, to zachęcam Cię do sprawdzenia książki „Labirynty Scruma„. Jeśli oglądasz ten odcinek podcastu, to właśnie możesz tę książkę zobaczyć. Znajdziesz w niej ponad 150 sprawdzonych rozwiązań na najczęstsze pułapki w Scrumie z rekomendacjami, czy pomysłami na to, czego warto spróbować, żeby te problemy rozwiązać. Książka cały czas jest dostępna i w wersji papierowej i w wersji ebookowej i na Kindle i na inne czytniki. I także jest dostępna w wersji takiej pakietowej. Czyli wersja i papierowa i e-booki i dodatkowo do tego jest wydrukowana checklista, której możesz użyć i sprawdzić, w które pułapki Scruma wpada Twój zespół. No i przy użyciu książki spróbować te problemy rozwiązać.

Kuba: Książkę możesz znaleźć pod adresem labiryntyscruma.pl. Ja sam mocno książkę Jacka rekomenduję. Osoby, które ze mną współpracują, często słyszą ode mnie to, że wiele z tych rzeczy, o których rozmawiamy w sesjach jeden na jeden, czy takie rzeczy jak dzisiaj w odcinku, tak naprawdę są świetnie pokryte w takim bardzo przejrzystym,  bardzo ustrukturyzowanym kształcie, właśnie w książce Jacka. Więc zwłaszcza jeśli Scrum jest czymś, z czego korzystasz, albo w czym chcesz się rozwijać, no to uważam, że Labirynty Scruma to pozycja obowiązkowa. 

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba. 

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.