Blog

Jednym z artefaktów w metodzie Scrum jest Backlog Sprintu. Obejmuje on listę zagadnień, którymi w czasie Sprintu zajmował się będzie Zespół aby osiągnąć Cel Sprintu uzgodniony z Właścicielem Produktu. Celowo określam elementy Backlogu Sprintu zagadnieniami, zamiast pisać o zadaniach, bo też w Backlogu tym znajdować się mogą zarówno wymagania, nad którymi Zespół pracuje, błędy do rozwiązania, usprawnienia z ostatniej Retrospekcji czy zadania techniczne związane z narzędziami i praktykami wykorzystywanymi przez Zespół. Ponieważ to Zespół Developerski jest właścicielem Backlogu Sprintu, sam decyduje o jego zawartości i formie. Ta ostatnia często przybiera postać tablicy kanbanowej, służąc od razu jako radiator informacji na temat tego, co dzieje się w Sprincie.

Większość elementów wspomnianego Backlogu definiowana jest w czasie Planowania Sprintu, gdy Zespół w oparciu o prognozę tego, co zdoła zrobić, identyfikuje jak chce to zrobić. Czasami wymagania (na przykład w formie Historyjek Użytkownika) są tak małe, że ich dalsza dekompozycja na potrzeby pracy w Sprincie już nie ma sensu; zazwyczaj jednak taka dekompozycja następuje, choćby po to, by ułatwić pracę nad jednym wymaganiem kilku osobom i aby jawnie określić „rzeczy do zrobienia”.

Jak zbudować Backlog Sprintu?

Istnieje wiele strategii dekompozycji wymagań na elementy Backlogu Sprintu. Wciąż warto próbować wycinać takie „kawałki”, które będą wartościowe same w sobie (vertical slices), natomiast często nie jest to możliwe. W takiej sytuacji gros zespołów identyfikuje po prostu techniczne zadania albo niezbędne zmiany konfiguracyjne i na ich realizacji skupia się w Sprincie. Objawem tego są elementy Backlogu Sprintu typu „dodać nową kolumnę do tabeli z zamówieniami” albo „skonfigurować kolejki dla wiadomości z loggera transakcji”; teoretycznie dobrze definiują one, co należy zrobić, ale mają jedną ogromną wadę – ukończenie takich zadań nie daje samo w sobie żadnej wartości.

Dobrą strategią jest wykorzystanie tego, co każde dobrze zdefiniowane wymaganie powinno posiadać: Kryteriów Akceptacyjnych. Zamiast dekomponować wymaganie na zadania techniczne, można pokusić się o podział oparty na scenariuszach akceptacyjnych. W ten sposób powstaną elementy Backlogu Sprintu typu „umożliwić logowanie rozpoczęcia transakcji” lub „zapisać identyfikator sposobu płatności wraz z danymi zamówienia”. Teoretycznie wciąż przekłada się to na techniczne zadania zmiany systemu logowania i rozbudowania schematu bazy danych, ale Zespół idzie o krok dalej: nie tylko wykonuje te zmiany, ale też używa ich do zrealizowania czegoś, co ma wymierną wartość z punktu widzenia uzgodnionego Celu Sprintu.

Gherkin może nam pomóc

Często jednak jest tak, że te scenariusze akceptacyjne są zbyt złożone, by dekompozycję wprost na nich opartą przeprowadzić. Co wtedy? Dobrą praktyką jest takie formułowanie Kryteriów Akceptacyjnych, by opisywały one zachowania systemu – w szczególności warto sięgnąć po składnię GWT („given” – „when” – „then” z praktyk BDD, czyli język gherkin), która uporządkuje strukturę scenariuszy akceptacyjnych. Mając tak zapisane Kryteria, można dokonać dekompozycji na poszczególne elementy scenariusza. Wtedy osobnym zagadnieniem staje się doprowadzenie do możliwości spełnienia warunków początkowych (opisanych w klauzuli „given”), osobnym wykonania akcji („when”), a osobnym możliwość oceny skutków („then”). Jako że przekładać się to będzie na tworzenie nowych testów, nowej funkcjonalności albo zmian konfiguracji, zrealizowanie tak zdefiniowanych zadań również efektywnie przybliża zespół do osiągnięcia Celu Sprintu.

Jak to może zadziałać? Załóżmy, że realizowane w Sprincie wymaganie dotyczy działania sklepu internetowego. Właściciel zdecydował się na wprowadzenie systemu lojalnościowego, który w zależności od kwoty wydanej na zamówienia w ostatnim roku nalicza rabaty w czasie kolejnych zakupów. Zespół podjął się realizacji wymagania, by dało się uruchomić mechanizm rabatowy działający automatycznie. Jedno z Kryteriów Akceptacyjnych zostało zapisane następująco:

Given: auto-discount feature is enabled
And: auto-discount feature is limited to buyers from restricted range of IP addresses
When: buyer pays for an order
And: buyer has paid at least one order during last 12 months
And: IP address of buyer falls in allowed range
Then: net price of order is reduced by 5% of net prices paid during last 12 months

Zespół może na przykład zdefiniować następujące elementy Backlogu Sprintu związane z tym wymaganiem:

• Implement feature on-off switch („auto-discount feature is enabled”)
• Allow IP filtering configuration („auto-discount feature is limited to buyer from restricted range of IP addresses”)
• Create or update buyer test suite („buyer pays for an order”)
• Update test framework to allow setting user order history for buyers („buyer has paid at least one order during last 12 months”)
• Update test framework to allow simulating different IP address of buyer („IP address of buyer falls in allowed range”)
• Implement mechanism to check for IP address during payment („IP address of buyer falls in allowed range”)
• Implement mechanism to apply discount („net price of order is reduced by 5% of net prices of orders paid during last 12 months”)
• Add check for IP address allowance when applying discount („IP address of buyer falls in allowed range”)
• Add check for account balance when applying discount („buyer has paid at least one order during last 12 months”)
• Update test framework to allow checking discount works („net price of order is reduced by 5% of net prices of orders paid during last 12 months”)

Mając tak zdefiniowane elementy Backlogu Sprintu dużo łatwiej określić, w jakiej kolejności powinny być realizowane (na przykład niekoniecznie będzie dało się na początku uaktualnić istniejące testy, ciężko też dodać filtrowanie adresów IP zanim w ogóle powstanie mechanizm naliczania rabatów etc.). Każde z takich zagadnień, kiedy zostanie zrealizowane, oznacza wymierny postęp prac, ponieważ albo rozszerza możliwości rozwijanego produktu, albo umożliwia integrację, testowanie, zrobienie kolejnego kroku w implementacji. Przy okazji widać, że zagadnienia te nie są przesadnie małe, co zabezpiecza Zespół przed utonięciem pod setkami zadań technicznych i utracenia z oczu Celu, który chce osiągnąć.

Dekompozycja oparta na Kryteriach Akceptacyjnych lub innych nie-technicznych kryteriach ma dodatkową zaletę, a mianowicie przymusza (w pozytywny sposób) Zespół do wspólnej pracy nad większością z tak zdefiniowanych zagadnień. Dość skutecznie uczy to Developerów wychodzenia poza obszary, które są najbliższe ich podstawowym kompetencjom. Nie będzie już zadania dla „bazodanowca” związanego tylko z bazą danych, nie będzie zadania dla „testera” mówiącego, że coś trzeba zweryfikować etc.

Jak stwierdzić, czy Cel Sprintu jest nadal osiągalny?

Wydzielania zadań stricte technicznych, które same wartości nie dają lepiej unikać (nie dają wartości, bo ciężko, na przykład, użyć nowej tabeli w bazie danych jeśli nie napisany jeszcze został mechanizm komunikacji z tą bazą). Praca w oparciu o takie zadania zwiększa ryzyko, że Zespół będzie ciężko pracował i miał poczucie, że posuwa się żwawo do przodu, zostawiając sobie zintegrowanie jakiegokolwiek działającego rozwiązania na stosunkowo późny moment w Sprincie. Często okazuje się, że uda się zrobić prawie wszystko (czyli teoretycznie niewiele brakuje do osiągnięcia Celu Sprintu), ale problemy integracyjne będą na tyle duże, że zabraknie czasu na ich rozwiązanie.

Pamiętać należy, że sposób budowania Backlogu Sprintu ma wymierne przełożenie na to, jak zespół może mierzyć postęp prac i jakie metryki potrafi dla siebie zidentyfikować. Typowym obrazkiem, jaki można zobaczyć w wielu zespołach, jest tablica obwieszona zadaniami technicznymi wyszacowanymi w godzinach i wykres spalania Sprintu odnoszący się do tychże szacunków. Jak już wspomniałem, może to dawać pozory postępu, gdy wykonujemy elementy składowe jakiegoś wymagania (godzin ubywa) ale samo wymaganie jak nie było, to nie jest jeszcze zrealizowane.

Z drugiej strony skupianie się wyłącznie na szacunkach zaakceptowanych do Sprintu wymagań (określonych na przykład w Story Pointach) niekoniecznie zadziała efektywnie. To, co dobrze sprawdza się Właścicielowi Produktu przy planowaniu wydań, niekoniecznie jest dostatecznie precyzyjne dla Zespołu, bo schodkowy wykres spalania Story Pointów wymagań zbyt późno pokaże, że development ugrzązł w miejscu. Zresztą, przyjmując, że dokonujemy podziału tych wymagań na mniejsze elementy Backlogu Sprintu, warto wykorzystać ich istnienie.

Odchodząc od dekompozycji na zadania techniczne na rzecz bardziej biznesowo zorientowanej strategii można odejść również od szacowania takich zagadnień w godzinach. Najprościej zastosować na przykład na połówki dni – jednostki wystarczająco małe, a już nie wymagające precyzji podczas planowania. Dużo lepszym pomysłem jest „rozpisanie” Story Pointów ze zdekomponowanego wymagania na wydzielone w tym procesie elementy Backlogu Sprintu. Aby mierzyć postęp, możliwe wtedy staje się wyrysowanie nie tyle wykresu spalania Sprintu, co wykresu przyrostu wartości w Sprincie.

Wracając do opisanego wcześniej przykładu: jeśli wymaganie było wyszacowane na 13 punktów i miało trzy Kryteria Akceptacyjne, Zespół oszacował, że z tych 13 punktów na scenariusz opisany powyżej przypada pięć. Ponieważ zidentyfikowanych zostało 10 elementów Backlogu Sprintu, Zespół każdemu z nich dał wagę 0.5 punktu uznając, że każdy element jest równie pracochłonny. W miarę, jak kolejne z tych zadań-zagadnień zostaną zrealizowane, punkty im przypisane będą dodawane do wykresu pokazującego przyrost wartości (sumy punktów zrealizowanych elementów Backlogu Sprintu) wraz z kolejnymi dniami Sprintu. Może to wyglądać na przykład tak:

Zielona linia pokazuje rzeczywisty przyrost, czerwona pokazuje, co jest do zrobienia, czyli zakres lub rozmiar Backlogu Sprintu (36 punktów to suma szacunków wszystkich wymagań zaakceptowanych przez Zespół w czasie Planowania Sprintu). Jak widać, zielona linia w pewnym momencie opada co oznacza, że jedno z wcześniej zakończonych zagadnień wymagało poprawek – sytuacja typowa w czasie Sprintu, ale też sygnał dla Zespołu, że zaczyna mocno oddalać się od osiągnięcia uzgodnionego Celu.

A co z zadaniami typowo technicznymi?

Rzecz jasna wciąż będą się pojawiać, podobnie jak tematy związane z usprawnieniami zidentyfikowanymi przez Zespół w ramach Retrospektyw. Dlatego niekoniecznie Sprint Backlog zawsze dać się będzie zbudować z elementów definiowanych w ten sam sposób. Również błędy, jeśli Zespół nimi się zajmuje, stworzą osobną kategorię – rzadko miewają szacunki pracochłonności, najczęściej muszą zostać obsłużone w z góry narzucony sposób.

Zasadą, której warto się trzymać, jest konsekwentne umieszczanie w Backlogu Sprintu wszystkiego, nad czym Zespół pracuje lub planuje pracować w czasie Sprintu. Dobrze też, by zastanowić się nad tym co i jak wizualizujemy. To, co jest do zrobienia, warto pokazać na przykład na tablicy kanbanowej, która czytelnie wskaże, na jakim etapie jest konkretne zagadnienie. Natomiast wyrysowując czy to wykresy spalania Sprintu, czy wykresy przyrostu wartości w Sprincie, lepiej pominąć te zagadnienia, które nijak do osiągnięcia Celu Sprintu nas nie zbliżają. W przeciwnym razie możemy uwierzyć, że dobrze nam idzie, patrząc na ładny wykres, który pokazuje, ze dużo zrobiliśmy z tych rzeczy, które Celu Sprintu nie wspierają wcale.