Sprint Backlog jest jednym z artefaktów Scruma. Tak samo jak w przypadku pozostałych dwóch artefaktów (Przyrostu i Product Backlogu), jego zadaniem jest wnieść przejrzystość do procesu i umożliwiać codzienną inspekcję i adaptację. Kto odpowiada za Sprint Backlog i może go aktualizować? Czy Sprint Backlog może się zmieniać? Na te i inne pytania dotyczące Sprint Backlogu znajdziesz w poniższym artykule.
Czym jest Sprint Backlog?
Sprint Backlog jest jednym z trzech artefaktów Scruma. Jego głównym celem jest przejrzyste ukazywanie zadań, których podejmują się Developerzy w trakcie trwania Sprintu, by osiągnąć obrany Cel Sprintu.
Za Sprint Backlog odpowiadają Developerzy Zespołu Scrumowego. Tworzą go (w kooperacji z Product Ownerem) podczas Planowania oraz dbają by stale był aktualny i wspierał empiryzm procesu.
Dobry Sprint Backlog powinien odpowiadać na trzy pytania [1]:
#1 Po co?
Formalnym zobowiązaniem Developerów w stosunku do Sprint Backlogu jest Cel Sprintu. Powinien być jeden i wskazywać wartość realizowanych zadań. Najlepiej umieścić go na szczycie Sprint Backlogu, by Developerzy mieli do niego łatwy dostęp podczas trwania Sprintu.
Dobrze sformułowany Cel Sprintu daje Zespołowi elastyczność podejścia do jego realizacji. Wzmacnia skupienie i jednoczy działania Zespołu.
Choć Cel Sprintu pozostaje jeden i niezmienny w trakcie trwania całego Sprintu, to Scrum daje opcję na renegocjację jego zakresu. W przypadku odkrycia nowych informacji lub napotkania nieprzewidzianych sytuacji w trakcie Sprintu, Developerzy współpracując z Product Ownerem, mogą uzgodnić nowy zakres, który umożliwi osiągnięcie Celu Sprintu.
Jeżeli jesteś ciekawy jak tworzyć dobre Cele Sprintów i nie wpadać w popularne pułapki, to zachęcam Cię do przeczytania artykułu, który napisałam dla portalu Product Vision.
#2 Co?
Developerzy we współpracy z Product Ownerem decydują, które elementy Product Backlogu zostaną wybrane do realizacji w Sprincie, by umożliwić osiągnięcie wyznaczonego Celu Sprintu.
W trakcie trwania Sprintu i zdobywania przez Zespół nowych informacji może okazać się, że niektóre elementy wybrane podczas Planowania wymagają aktualizacji lub stają się nieaktualne. Nie ma w tym nic nadzwyczajnego, a Zespół powinien podjąć odpowiednie kroki, w celu dostosowania się do nowej sytuacji (np. renegocjacja zakresu Sprintu).
#3 Jak?
Plan na realizację wybranych elementów Product Backlogu ustalają Developerzy podczas Planowania. Plan ten ma doprowadzić Zespół do dostarczenia ukończonego Przyrostu. Konieczne jest zatem uwzględnienie wymagań, które nakłada na Przyrost Definicja Ukończenia (np. testy, wdrożenia, wymagania formalne).
Nie ma tu miejsca na micro-management. Plan powinni tworzyć Developerzy, gdyż tylko takie podejście wspiera ich samoorganizację i odpowiedzialność za wyniki pracy (łatwiej się zobowiązać do realizacji samodzielnie utworzonego planu, niż narzucanego przez osobę trzecią).
Jak tworzyć Sprint Backlog?
Nie ma jednego prawidłowego sposobu na tworzenie Sprint Backlogu. Najważniejsze jest by wybrane metody pasowały Zespołowi. Niektórzy lubią dokładnie planować poszczególne etapy każdego z PBI, tworząc obszerną liczbę tasków. Inni stawiają na mniej formalną formę planowania. Metoda pozostaje dowolna, o ile wynik tworzy odpowiedni poziom szczegółów i przejrzystości, by możliwa była na ich podstawie inspekcja i adaptacja.
Sprint Backlog a empiryzm
Sprint Backlog ma duże znaczenie dla empiryzmu procesu scrumowego. Jest narzędziem, które ułatwia Developerom śledzenie postępów ich prac w kierunku osiągnięcia Celu Sprintu. Przejrzyście pokazuje aktualną sytuację, dając wszystkim w Zespole tą samą bazę do dokonywania inspekcji i planowania adaptacji.
Sprint Backlog a przejrzystość
Sprint Backlog, odpowiadający na trzy omówione wcześniej pytania, tworzy przejrzystość.
Cel Sprintu wskazuje wartość i ułatwia Zespołowi i Interesariuszom zrozumieć powody stojące za wykonywaną pracą. Tworzy w Zespole poczucie sensu i odpowiedzialności za wytworzenie Przyrostu. Ułatwia podejmowanie decyzji w trakcie trwania Sprintu.
Wybrane elementy i plan na ich realizacje umożliwiają śledzenie postępów w drodze do osiągnięcia Celu Sprintu i wytworzenia ukończonego Przyrostu. Usprawnienia zidentyfikowane podczas Retrospektyw, będące elementami Sprint Backlogu, przejrzyście ukazują starania Zespołu podejmowane w celu usprawnienia procesu wytwórczego [2].
Regularnie aktualizowany Sprint Backlog pokazuje obecny stan rozwoju Produktu. Daje poczucie jasności i zrozumienia sytuacji pośród wszystkich zaangażowany w proces wytwórczy – Developerów, ale również Interesariuszy i organizacji.
Sprint Backlog a inspekcja i adaptacja
Każdego dnia Developerzy dokonują inspekcji, która umożliwia im identyfikację odchyleń od optymalnej ścieżki do osiągnięcia Celu Sprintu i wygenerowania ukończonego Przyrostu. Sprint Backlog ułatwia to zadanie, dzięki przejrzystemu ukazywaniu bieżącej pracy. Podczas inspekcji Developerzy obserwują czy Cel Sprintu jest nadal możliwy do osiągnięcia, czy elementy, które zostały wybrane umożliwiają jego realizacje, a plan nadal pozostaje aktualny [3].
Gdy odchylenia są zidentyfikowane, konieczne zmiany nanoszone są do Sprint Backlogu w ramach adaptacji. Jest to potrzebne by stale utrzymywać jego zdolność do przejrzystego ukazywania bieżącej pracy. Sprint Backlog może być zmieniany w dowolnym momencie i dotyczyć dowolnego kawałka pracy.
Czy Sprint Backlog może się zmieniać?
Niektórzy myślą, że Sprint Backlog nie może się zmieniać, bo zaburzać to będzie np. estymaty PBI’ów, zbierane metryki, wyliczone prędkości dostarczania [5]. To z kolei uniemożliwi dokonywanie dokładnych prognoz. Takie podejście zakłada, że jesteśmy w stanie przewidzieć przebieg wydarzeń w złożonym środowisku. Gdyby tak było, niepotrzebny byłby nam empiryzm.
Musimy pogodzić się z faktem, że najwięcej uczymy się poprzez doświadczenie, a zatem w wyniku realizacji zadań. W szybko zmieniających się środowiskach nie przewidzimy wszystkiego, nawet na tak krótkim odcinku czasu jakim jest Sprint. Każdy Zespół, który to rozumie, nie będzie miał problemów, żeby dokonywać koniecznych zmian w Sprint Backlogu ustalonym podczas Planowania.
Każdorazowo w wyniku Daily Scruma może nadarzyć się konieczność zmiany Sprint Backlogu. Może to oznaczać np. dodanie nowego PBI, bo Developerzy nie przewidzieli czegoś w trakcie Planowania; usunięcie PBI, bo w wyniku wykonanej pracy inny element okazał się nie być już potrzebny; czy aktualizację zawartości PBI, bo nowe informacje wymusiły na Zespole zmianę oryginalnego pomysłu na realizację zadania. Tego typu zmiany będą się zdarzać i są dobre.
Nie powinno się jednak dokonywać zmian, które narażałyby osiągnięcie Celu Sprintu. Warto pamiętać, że podczas Planowania Zespół zobowiązuje się do osiągnięcia celu, a nie realizacji ustalonego Sprint Backlogu. Cel Sprintu pozostaje jeden i niezmienny przez cały czas trwania Sprintu, natomiast Sprint Backlog może stale ewoluować, by maksymalizować szansę Zespołu na dostarczenie wartościowego Przyrostu.
Wracając natomiast do metryk… Są pomocne w empirycznym podejściu jako narzędzie ułatwiające podejmowanie decyzji. Nie mogą być jednak sensem pracy Zespołu oraz blokować inspekcji i adaptacji. Najważniejsze dla nas zawsze powinno być dostarczanie wartości dla użytkowników.
Podsumowanie
Sprint Backlog jest stale zmieniającym się artefaktem Scruma. Każdy z jego trzech elementów (Cel Sprintu, wybrane elementy i plan ich realizacji) tworzą przejrzystość oraz ułatwiają inspekcję i adaptację. I choć zmiany nanoszone na Sprint Backlog mogą zaburzać zbierane metryki i wyniki prognoz, to nie powinno nas to blokować przed dokonywaniem koniecznych aktualizacji. Tylko Sprint Backlog, który jest stale dostosowywany do bieżącej sytuacji, może zapewnić maksymalizację wartości dostarczanej przez ukończony Przyrost spełniający ustalony Cel Sprintu.
Bibliografia
[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[2] The importance of Transparency and the Sprint Backlog (07); https://www.scrum.org/resources/blog/importance-transparency-and-sprint-backlog-07
[3] Inspection and the Sprint Backlog (18); https://www.scrum.org/resources/blog/inspection-and-sprint-backlog-18
[4] How the Sprint Backlog Supports Adaptation (29); https://www.scrum.org/resources/blog/how-sprint-backlog-supports-adaptation-29
[5] YDS: Can the Sprint Backlog Change During a Sprint?; https://www.youtube.com/watch?v=xR7aONNqUOc