Bardzo mało zespołów posiada Cel Produktu. Jeszcze mniej ma Cel Sprintu. Moim zdaniem obie te rzeczy są ze sobą powiązane. Stawiam nawet śmiałą tezę, że nie masz Celu Sprintu, bo brakuje Ci Celu Produktu.
Cel… czego?
Celowość tego wszystkiego przedstawiałem, gdy po raz pierwszy opisywałem Cel Produktu. Pozwolę sobie jednak powtórzyć podstawy podstaw. Zacznijmy od tego, że Product Owner posiada wizję, to znaczy ma jakieś wyobrażenie co do tego, jak produkt końcowy powinien wyglądać. Jeżeli rozwijamy już istniejące rozwiązanie, to PO powinien posiadać wizję rozwoju. Fajnie by było mieć może jakąś roadmapę, może jakieś oczekiwania, a na pewno backlog.
W backlogu na ogół powinniśmy mieć wymagania, które są ułożone od tych najważniejszych i najbardziej pilnych, do tych które są życzeniami, marzeniami i dalszymi planami. Ta kolejność powinna mieć swoje potwierdzenie w jasno sformułowanym Celu Produktu. Rozumiemy przez to słowno-muzyczny zapis tego, co chcemy osiągnąć zanim rozejrzymy się, gdzie chcemy iść dalej. To ostatnie zdanie będzie ważne za chwilę.
Można powiedzieć że Cel Produktu to pierwszy krok do tego, żeby osiągnąć wizję, która jest zwykle rozmyta i nieprecyzyjna. Analogicznie Cel Sprintu jest to cel bieżącej iteracji, która ma nas doprowadzić przynajmniej jeden krok w kierunku spełnienia aktualnego Celu Produktu. Analogicznie, Sprint Backlog odzwierciedla Cel Sprintu. Trudno żeby nazwany cel był czymś zupełnie innym, niż wymagania które mamy zamiar realizować.
I tu zaczynają się schody.
Problemy z Celem Sprintu
W naturze występuje wiele problemów z Celem Sprintu. Przede wszystkim zespoły próbują zmieścić tam więcej niż jedną rzecz. To trochę dziwne, że próbujemy skupić się na więcej niż jednej rzeczy. Przecież w samym słowie „skupić się” zawiera się jakaś jednostkowość.
Nawet jeśli Cel Sprintu nie składa się z trzech czy czterech rzeczy wymienionych po przecinku, to niestety często ustalany jest on nie przez cały Scrum Team, tylko jednoosobowo przez Product Ownera. To też niedobrze. PO co prawda powinien posiadać jakieś oczekiwania co do bieżącego Sprintu, a cel powinniśmy sformułować razem jako wypadkowa oczekiwań i tego co sobie zaplanowaliśmy.
Ale te dwa problemy to i tak „pikuś” w porównaniu z tym co się dzieje najczęściej. W przerażającej większości zespołów scrumowych, Celu Sprintu w ogóle nie ma. Nikt go nie czuje, nikt go nie definiuje, nie odczuwamy żadnej potrzeby posiadania go. Co więcej, nie widzimy absolutnie żadnych negatywnych konsekwencji związanych z tym że celu nie ma.
A skoro nie ma konsekwencji, to po co to robić?
W kierunku Celu Produktu
Teza: gdybyśmy tylko mieli Cel Produktu, to łatwiej byłoby nam nazwać Cel Sprintu. Cel Produktu to jakiś określony stan naszego rozwiązania, który chcemy osiągnąć w kilka-kilkanaście Sprintów. To znaczy, że jest to realna i wstępnie zdefiniowana praca, którą prawie na pewno już mamy w Backlogu Produktu i którą będziemy wykonywać Sprint po Sprincie.
I tu wracamy do zdania uprzednio wskazanego jako ważne. To nie jest tak, że mamy z góry zaplanowane Cele Produktu na najbliższe 3 lata, aż w końcu osiągniemy naszą wizję! To jest zupełne przeciwieństwo zwinności, bo z góry zakładamy że nic się przez 3 lata nie zmieni. Udajemy też, że doskonale wiemy co chcemy wytworzyć, nie wpadniemy na nowe pomysły, nie zmienią się wymagania, nie spróbujemy innych rozwiązań, ani nie zmieniają się potrzeby czy rynek.
W podejściu zwinnym, jeżeli już coś planujemy, to krótki okres, który możemy przewidzieć. I dopiero po upływie tego okresu, bądź wcześniejszemu odniesieniu sukcesu/porażki, zastanowimy się co dalej. Cel Produktu co prawda nie definiuje nam żadnego okresu, bo nie jest to kamień milowy ze ściśle wyznaczoną datą, ale jest to pewne miejsce do którego chcemy dotrzeć całkiem niedługo. I jako taki jest jedyną rzeczą, którą mamy zaplanowaną w kontekście dążenia do naszej wizji. Jak go osiągniemy bądź porzucimy, to wtedy się zastanowimy „Co dalej?”.
Oczywiście było by świetnie, gdyby nasz Product Owner posiadał z tyłu głowy jakąś roadmapę albo ogólny plan na to, jak chce dotrzeć do tej wizji. Nie chcemy mieć sytuacji rodem z memów, gdzie plan to „1. Pierwszy Cel Produktu 2. … 3. Profit”. PO musi mieć wizje i umieć zarazić ją ludzi, ale powinien też być w stanie opowiedzieć, jak do tej wizji zamierzamy dotrzeć. Nawet jeżeli po drodze mamy dużo niewiadomych, które odkryjemy z czasem.
Cel Produktu kontra Cel Sprintu
Posiadając Cel Produktu łatwiej nam jest wyznaczać Cele Sprintów. Te ostatnie będą po prostu kolejnymi krokami w kierunku tego pierwszego. To dość oczywiste i proste, jeżeli w ogóle zastanawiamy się nad tym, co robimy, a nie po prostu bezmyślnie robimy Sprint po Sprincie.
Jest mnóstwo zespołów które bezrefleksyjnie realizują wszystkie zgłoszenia pochodzące od klienta albo spełniają po kolei wszystkie wymagania określone w karcie projektu bądź w specyfikacji istotnych warunków zamówienia. Nie tędy (scrumowa) droga.
Tutaj trzeba podkreślić, że czasami zdarzy się, że Cel Sprintu nijak będzie się miał do naszego zdefiniowanego Celu Produktu. Jeżeli naszym Celem Produktu jest dwujęzyczna wersja naszej aplikacji na rynki zagraniczne, ale w tym Sprincie musimy pilnie wdrożyć wszystkie zmiany wynikające z Polskiego Ładu, to jest to zrozumiałe. Natomiast taka sytuacja jasno pokazuje że tym razem Cel Sprintu ma się nijak do naszego Celu Produktu. To pozwala nam zastanowić się nad tym, co właściwie robimy, czy na pewno ta sytuacja jest pożądana i czy mamy dobrze zdefiniowane cele.
Sytuacja w której co Sprint robimy rzeczy, które nie mają absolutnie żadnego przełożenia na zdefiniowany Cel Produktu, to dla nas jasny sygnał, że albo tenże jest źle określony i powinniśmy go zmienić, albo nasze prace które planujemy na każdy Sprint są nie tym co powinniśmy robić. Nie uzyskamy takiej informacji wprost bez nazwanych i spisanych: Celu Produktu i Celu Sprintu.
A to oczywiście nie jedyna korzyść z tych zobowiązań. Przede wszystkim będziemy wiedzieć do czego dążymy, a cały zespół będzie mógł skupić się na tym, co najważniejsze. Naprawdę nie ma żadnego powodu, żeby nie mieć obu celów zdefiniowanych i spisanych. No chyba, że nie pracujemy w Scrumie, ale w czymś co Scrum tylko przypomina.
