Nowy Backlog Sprintu jest akceptowany przez Zespół Developerski podczas Planowania Sprintu (Sprint Planning). Od tej chwili staje się aktualnym zobowiązaniem Developerów, czyli listą nowych funkcjonalności, ulepszeń i modyfikacji Produktu, które powstaną w rozpoczynającym się Sprincie. Po rozpoczęciu Sprintu Backlog ten staje się natomiast obowiązującą kolejką, z której Developerzy wybierają zadania do wykonania.
Sprint Backlog opisujepracę Zespołu Developerskiego w czasie trwania jednego Sprintu. Dlatego też wyrażony jest w języku technicznym. Opisuje szczegółowe zadania i ich planowane rozwiązania. Składa się więc z listy zadań sporządzonej w sposób czytelny dla Developerów. Backlog Sprintu zwykle w niewielkim stopniu uwzględnia język wartości biznesowej Produktu, czyli sposób opisywania właściwy Backlogowi Produktu, który przybliżamy tutaj.
Backlog Sprintu jest tworzony:
Podczas Planowania Sprintu Product Owner proponuje, w jaki sposób w najbliższym Sprincie zwiększyć wartość Produktu. Następnie cały Scrum Team współpracuje nad sformułowaniem Celu Sprintu, czyli wybiera z Backlogu Produktu funkcjonalność, którą będzie realizował. Cel Sprintu określa, w jaki sposób zostanie ulepszony bądź rozbudowany Produkt, aby mógł lepiej spełniać oczekiwania Klienta.
Kolejnym krokiem jest zastanowienie się, jaki zakres prac jest realny do wykonania w najbliższym Sprincie. I w jaki sposób ta praca zostanie wykonana.
Rezultaty tych ustaleń zostają spisane w formie technicznego opisu zadań do wykonania. I ta lista właśnie staje się nowym Backlogiem Sprintu.
Nowopowstały Backlog Sprintu zostaje umieszczony w miejscu łatwo dostępnym dla wszystkich członków Zespołu Developerskiego. W przestrzeni fizycznej zwykle jest to tablica umieszczona w miejscu pracy. Natomiast w przestrzeni cyfrowej – współdzielony dokument, który mogą aktualizować wszyscy Developerzy. Chociaż właścicielem Backlogu Sprintu jest cały Scrum Team i wszyscy jego członkowie powinni dbać o jego aktualizację, zwykle zadaniem tym zajmuje się Scrum Master lub jeden z Developerów.
Backlog Produktu nie określa sposobu wykonywania zadań. Dzieje się tak, ponieważ pozostawienie swobody wyboru postępowania jest bardzo ważne dla samoorganizacji Zespołu Developerskiego. Wolność wyboru kolejności i metod działania jest ważna także dla poczucia samodzielności i odpowiedzialności każdego z Developerów.
Temu samemu celowi służy potraktowanie Backlogu Sprintu jako nieuporządkowanej listy zadań do wykonania. Developer wybiera z niej zadanie, które akurat może lub ma ochotę wykonać (pull). Jest to przeciwieństwo tradycyjnego modelu push, w którym zadania są narzucane Zespołowi lub Developerowi w określonej z góry kolejności.
Backlog Sprintu określa:
Postęp prac spisanych w Sprint Backlogu jest odzwierciedlany przez narzędzia metryczne. Najczęściej przez Burndown Chart, który napiszemy szczegółowo w osobnym artykule. Dzięki takiej wizualizacji Zespół Developerski może łatwo zorientować się, czy prace nad realizacją Celu Sprintu idą zgodnie z przewidywaniami.
Może się zdarzyć, że w czasie trwania Sprintu okazuje się, że plan prac został zakreślony nierealistycznie. Innymi słowy, ilość zadań zapisanych w Backlogu Produktu, które są potrzebne do realizacji Celu Sprintu, jest zbyt duża lub zbyt mała. W takim przypadku Developerzy negocjują z Product Ownerem zmiany w bieżącym Sprint Backlogu. Możliwe jest bowiem zmniejszenie ilości prac lub też dobranie dodatkowych zadań z Backlogu Produktu, bądź rozbudowanie planowanych już rozwiązań. Zmiany nie mogą jednak dotyczyć Celu Sprintu.
Backlog Sprintu to lista zadań, jakie zobowiązują się wykonać Developerzy w czasie trwania jednego Sprintu. Jest swego rodzaju szczegółową umową zawieraną z Product Ownerem. Backlog Sprintu powstaje w czasie Planowania Sprintu, w którym bierze udział cały Scrum Team. Natomiast stopień wykonania zadań przyjętych do realizacji odzwierciedla Burndown Chart.
Sprawdź również: Co to jest Backlog Produktu?
Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.
Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…
Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…
Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…
Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…
Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…
“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…