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 Product Ownerem. Celowo określam elementy Backlogu Sprintu zagadnieniami, zamiast pisać o zadaniach, bo też w Backlogu tym znajdować się mogą wymagania, nad którymi Zespół pracuje, błędy do rozwiązania, usprawnienia z ostatniej Retrospekcji, czy też zadania techniczne związane z narzędziami i praktykami wykorzystywanymi przez Zespół. Ponieważ to Developerzy są właścicielami Backlogu Sprintu, sami decydują 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ół na podstawie prognozy tego, co zdoła zrobić, określa, w jaki sposób 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ć wspólną 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. Warto wycinać takie kawałki, które będą wartościowe same w sobie (ang. vertical slices), natomiast często nie jest to możliwe. W takiej sytuacji większość 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 mechanizmu logowania 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. Dopiero zrealizowanie całego ich zestawu faktycznie zmienia zachowanie produktu.
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 Developerzy idą o krok dalej: nie tylko wykonują te zmiany, ale też używają 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 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) znaną z praktyki 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 pojedynczym elementem Backlogu Sprintu staje się doprowadzenie do możliwości spełnienia warunków początkowych (opisanych w klauzuli given), innym elementem będzie możliwość wykonania akcji przez użytkownika (when), a jeszcze kolejnym możliwość oceny skutków takiego działania (then). Jako że przekładać się to będzie na tworzenie nowych testów, nowej funkcjonalności albo zmian konfiguracji, zrealizowanie któregokolwiek z tak zdefiniowanych elementów Backlogu Sprintu efektywnie przybliża Zespół do osiągnięcia Celu Sprintu.
Jak to wygląda w praktyce? Załóżmy, że Zespół rozwija mechanizmy dużego sklepu internetowego. Product Owner 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. Stosowny element Backlogu Produktu, opisujący mechanizm rabatowy działający automatycznie, został dodany do Backlogu Produktu.
W czasie Planowania Sprintu Developerzy podjęli do realizacji kilka wymagań, w tym i to związane z wyliczeniem rabatów. Ma ono zdefiniowane trzy kryteria akceptacyjne. Rozważmy jedno z nich, które zostało zapisane następująco, jako scenariusz behawioralny:
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
Ponieważ zaspokojenie takiego kryterium akceptacji wymaga sporo pracy, Zespół postanowić podzielić je na następujące elementy Backlogu Sprintu (w nawiasach widać nawiązania do poszczególnych klauzul w scenariuszu akceptacyjnym):
1. Implement feature on-off switch
(auto-discount feature is enabled)
2. Allow IP filtering configuration
(auto-discount feature is limited to buyer from restricted range of IP addresses)
3. Create or update buyer test suite
(buyer pays for an order)
4. Update test framework to allow setting user order history for buyers
(buyer has paid at least one order during last 12 months)
5. Update test framework to allow simulating different IP address of buyer
(IP address of buyer falls in allowed range)
6. Implement mechanism to check for IP address during payment
(IP address of buyer falls in allowed range)
7. Implement mechanism to apply discount
(net price of order is reduced by 5% of net prices of orders paid during last 12 months)
8. Add check for IP address allowance when applying discount
(IP address of buyer falls in allowed range)
9. Add check for account balance when applying discount
(buyer has paid at least one order during last 12 months)
10. 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)
Dekompozycja oparta na kryteriach akceptacyjnych lub innych nietechnicznych kryteriach ma dodatkową zaletę, a mianowicie przymusza Developerów w pozytywny sposób do wspólnej pracy nad większością tak zdefiniowanych zagadnień. Dość skutecznie uczy to również Developerów wychodzenia poza obszary, które są najbliższe ich podstawowym kompetencjom. Nie będzie już zadania dla eksperta od baz danych, nie będzie zadania dla testera etc. – będą kolejne problemy do rozwiązania i rzeczy do zrobienia, a niemal każda wymagać będzie łączenia różnych kompetencji.
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 na podstawie takich zadań zwiększa ryzyko, że Developerzy będą ciężko pracować i mieć poczucie, że posuwają się żwawo do przodu, pozostawiając 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ół Scrum może mierzyć postęp prac i jakie miary potrafi w ogóle 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 (następuje spalenie zaplanowanych zadań), ale niekoniecznie oznacza to, że przybliżamy się jakkolwiek do realizacji działającej funkcjonalności.
Wszystko zależy od tego, w jakim stopniu zadania, które ciężkim wysiłkiem chłopa i robotnika realizujemy, są adekwatne do problemu, jaki rozwiązujemy. Może okazać się, że zrealizujemy je wszystkie, a Cel Sprintu, jaki mieliśmy osiągnąć, będzie równie odległy, jak na początku.
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ę Product Ownerowi przy prognozowaniu dat wydań, niekoniecznie jest dostatecznie precyzyjne dla Developerów w czasie Sprintu, 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, da się odejść również od szacowania takich zagadnień w godzinach. Można zastosować na przykład połówki dni – jednostki wciąż wystarczająco małe, a już niewymagające precyzji podczas Planowania. Dużo lepszym pomysłem jest rozdzielenie 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, ile wykresu przyrostu wartości w Sprincie.
Wracając do opisanego wcześniej przykładu związanego ze sklepem internetowym: jeśli wymaganie było wyszacowane na 13 punktów i miało trzy kryteria akceptacyjne, można rozłożyć te punkty na poszczególne scenariusze zależnie od ilości pracy, która będzie potrzebna do ich zaspokojenia.
Przyjmijmy, że Zespół przypisał do omawianego powyżej kryterium akceptacji (scenariusza opisanego językiem Gherkin) pięć z ogółu 13 story pointów. Osiem pozostałych punktów rozdzielone zostało na dwa kolejne kryteria akceptacji (nieomawiane w tym artykule).
Jak rozłożyć pięć story pointów przydzielonych do scenariusza na elementy Backlogu Sprintu, które powstały na jego podstawie? Ponieważ zidentyfikowanych zostało 10 takich elementów (ich lista została zaprezentowana we wcześniejszej części artykułu), Developerzy każdemu z nich przydzielili dokładnie tyle samo: pół punktu. Uznali bowiem, że choć każdy z tych elementów wymaga nieco innego nakładu pracy i czasu, zrealizowanie żadnego z nich nie potrwa dłużej, niż pół dnia – nie różnią się więc istotnie wielkością.
W miarę, jak kolejne z tych elementów Backlogu Sprintu zostaną zrealizowane, punkty im przypisane będą dodawane do wykresu pokazującego przyrost wartości wraz z kolejnymi dniami Sprintu. Może to wyglądać na przykład tak:
Zielona linia pokazuje rzeczywisty przyrost liczby ukończonych elementów Backlogu Sprintu (wycenionych w połówkach story pointu). Linia czerwona pokazuje, co jest do zrobienia, czyli jaki jest całkowity rozmiar Backlogu Sprintu (36 punktów to suma szacunków elementów Backlogu Sprintu dla wszystkich wymagań podjętych do realizacji 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 Retrospekcji Sprintu. Dlatego niekoniecznie Backlog Sprintu zawsze da się zbudować z tego samego typu 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 sposób narzucony z góry.
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ż 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 prac 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, że dużo zrobiliśmy, choć ani o krok nie zbliżyliśmy się do realizacji Celu.