Wszyscy musimy zgodzić się z jednym twierdzeniem: Cel Sprintu był do tej pory traktowany przez metodykę Scrum delikatnie mówiąc po macoszemu. Co zmieniło się w tym zakresie w nowym Scrum Guide? Jak wygląda Cel Sprintu 2020?
Ta niezręczna sytuacja
Chyba każdy z nas się kiedyś z tym spotkał. Kończymy Planowanie Sprintu i nadchodzi ten niezręczny moment, kiedy powinniśmy zrobić coś więcej. Tym czymś jest właśnie określenie Celu Sprintu. Najgorsze jakie widziałem, zresztą nie tylko ja, to cel mówiący o konieczności realizacji wszystkich elementów zaplanowanego właśnie Sprint Backlogu.
Nie po to się planujemy, bierzemy pod uwagę Capacity i Velocity, aby mieć tego typu rzeczy jako Cel Sprintu. Przecież planujemy się na 100% naszych możliwości. W kolejnych 2 tygodniach, zobowiązujemy się, że postaramy się tę pracę wykonać. Po co więc nam cel mówiący ponownie, że zrobimy wszystko?
Skoro więc nie „realizacja wszystkich” to co? I tutaj właśnie rozpoczynało się „szycie”. Jak wytłumaczyć, w zjadliwy sposób, co to jest ten Cel Sprintu i po co właściwie mamy go robić? Przed takim dylematem stanęło wielu z nas, wielu też poległo nie potrafiąc przełożyć tego na język scrumowy. Pragmatyzm? Nie w tym przypadku!
Cel Sprintu 2020
Z pomocą przyszła nam aktualizacja Scrum Guide dokonana w listopadzie 2020 roku. To właśnie wtedy Cel Sprintu otrzymał należne mu miejsce. Tak naprawdę niewiele się zmieniło, został on jednak umieszczony w odpowiednim miejscu i w odpowiednim czasie. Po nowemu Cel Sprintu to zobowiązanie. Zespół zobowiązuje się, że zrobi wszystko, aby zdefiniowany podczas Planowania Sprintu cel dostarczyć. Ale powiedzmy sobie szczerze, samo zobowiązanie nie powoduje, że cel stał się bardziej użyteczny.
Cel Sprintu to odpowiedź na pytanie PO CO budowany jest ten przyrost, PO CO realizowany jest Sprint. Mówi on jaką nową wartość otrzyma nasz Interesariusz po zakończeniu zaplanowanej właśnie iteracji. To w znaczący sposób uzupełnia znaczenie Celu Sprintu znane nam dotychczas. Prócz najważniejszej rzeczy, która skupiała deweloperów w Sprincie mamy odpowiedzieć teraz na pytanie o to, co klient będzie miał nowego, z czego będzie mógł potencjalnie skorzystać. Ta właśnie zmiana powoduje, że określenie Celu Sprintu powinno być dużo łatwiejsze niż dotychczas.
Jest jeszcze jedna zmiana. Cel Sprintu finalnie powinien znaleźć się w Backlogu Sprintu jako transparentne zobowiązanie Developerów do pełnego zaangażowania w osiągnięcie Celu Sprintu. Mieliśmy już jeden tego typu eksperyment. Pamiętacie? Najważniejsze usprawnienie ze Sprint Retrospective miało znajdować się w Backlogu Sprintu. Efekty tego eksperymentu są jasne i oczywiste. W tym jednak przypadku mam pewność, że sprawy potoczą się inaczej.
W końcu użyteczny!
Nie wiem, czy tylko ja tak mam, ale czuję, że ta subtelna zmiana spowodowała we mnie zupełnie nowe rozumienie tego Zobowiązania. W końcu Cel Sprintu stał się użytecznym narzędziem. Z jednej strony daje jasny sygnał Developerom co do priorytetów realizowanego Backlogu Sprintu. Z drugiej strony daje możliwość zarządczego spojrzenia, np. Prezesa i wyciągnięcia szybkiej, wiarygodnej informacji czym się zajmuje Zespól. Jest brakującym ogniwem otwierającym zupełnie nowe możliwości śledzenia postępów prac.
Cel Sprintu powinien być etapem do osiągnięcia Celu Produktu, innego nowego zobowiązania, o którym pisaliśmy w zeszłym tygodniu. Analizując Cele Sprintów, nawet retrospektywnie i weryfikując ich spełnienie, jesteśmy w stanie odpowiedzieć sobie na pytanie, gdzie jesteśmy na naszej Roadmapie Produktu. A tego, patrząc z pozycji zarządczej dziś brakowało. I to jest duża wartość dodana.
Na koniec pozostaje sposób oceny czy Cel Sprintu zdefiniowany na Planowaniu został przez Developerów osiągnięty. Spotkałem się już z praktyką, w której proponuje się stosowanie mierników i przypisanie ich do celu. Zdefiniujmy ich kilka, po zakończonym Sprincie przyłóżmy je do Przyrostu i sprawdźmy, czy się udało. Czy naprawdę tego potrzebujemy? Chyba nie.
Do sprawdzenia Celu Sprintu powinna nam wystarczyć weryfikacja, że zakładany krok w kierunku osiągnięcia Celu Produktu został właśnie zrealizowany. Czy nie wystarczy nam aprobata rozwiązania dokonana przez Product Ownera? To więcej niż najlepsze mierniki, które możemy zdefiniować. Pragmatyzm ma tutaj jak najbardziej zastosowanie.
