Jednym z wyników Planowania Sprintu jest uzgodniony przez Zespół Scrum Cel Sprintu. Wymóg, by Cel ten został nazwany, dodany został do Scruma kilka lat temu. Miało to ułatwiać Zespołom działanie – w tym samozarządzanie swoją pracą – ale obserwacja zdaje się pokazywać, że stało się dokładnie na odwrót. Cel Sprintu rodzi się często w bólach i jest wymęczonym, na siłę skleconym hasłem bez realnego znaczenia. Ma być zdefiniowany, no to jest, ale niczemu nie służy.

Kłopot z ustaleniem Celu Sprintu jest w istocie manifestacją jednego lub wielu problemów, nad którymi trzeba się pochylić. Można rzec, że empirycznie (a jakże!) dowiadujemy się czegoś o naszym produkcie, naszym Scrumie a często i o nas samych. Zanim jednak rozwinę tę myśl, warto przypomnieć, o co chodzi z tym Celem Sprintu.

„Po co?”

To jest pytanie, na które Cel Sprintu powinien odpowiadać: „po co odbywa się ten Sprint?”. Inaczej mówiąc, Cel Sprintu wyjaśnia, dlaczego zdecydowaliśmy się poświęcić czas i wysiłek na robienie akurat tych rzeczy, które podjęte zostały do realizacji z Backlogu Produktu. Co ma to dać interesariuszom, na których rzecz pracujemy? Jakiej korzyści (wartości) mogą się spodziewać, jeśli go osiągniemy? Co stanie się dzięki temu możliwe? Jaką wiedzę uzyskamy wraz z interesariuszami? Czego się wszyscy nauczymy?

Zwracam uwagę, że Celem Sprintu nie jest taka czy inna funkcjonalność produktu, jaka powstanie w ramach iteracji. Czy na pytanie „po co odbywa się ten Sprint?” sensowną odpowiedzią może być np. „formularz kontaktowy”? W oczywisty sposób nie. To powód, dla którego ten formularz powstaje, może być Celem Sprintu. Albo wyjaśnienie, co dzięki istnieniu tego formularza będzie możliwe, a na razie jest niewykonalne.

Cel Sprintu nie był formalnie częścią Scruma od samego początku, ale został dodany w pewnym momencie by – jak napisałem wcześniej – ułatwić pracę Zespołom. A także po to, by spowodować, że zaczną sobie one zadawać pytania o to, po co realizują kolejne Sprinty, jeśli dotąd tego nie robiły. Dla wszystkich dojrzałych użytkowników Scruma dołożenie Celu Sprintu to definicji metody nie było w ogóle zaskakujące, bo i bez formalnego wymogu, każdą iterację planowali po coś.

W jaki sposób Cel Sprintu pomaga Zespołom

Jeśli jasno określimy, do czego dążymy w Sprincie, wtedy staje się możliwe podejmowanie decyzji w odniesieniu do owego Celu. Jeśli mamy dwie możliwości zrobienia czegoś, wybierzemy tą, która Cel Sprintu pozwoli w ogóle osiągnąć, albo pozwoli to zrobić szybciej, lepiej, taniej itd. (niepotrzebne skreślić). To pierwszy powód, dla którego Cel Sprintu w Scrumie się pojawił.

Drugie ułatwienie: Cel Sprintu jest niezmienny i z niego wynika to, na czym Developerzy (i w sumie cały Zespół) powinien skupić się w trakcie iteracji. Wszelkie bzdurne opowieści o tym, że zakres prac w Sprincie nie może się zmieniać, zostały wrzucone do kosza. Zakres musi się zmieniać, jeśli to niezbędne do osiągnięcia Celu Sprintu. Idiotyzmem kompletnym byłoby realizować zaplanowane działania, gdy już wiadomo, że prowadzą one donikąd. Natomiast po to, aby zapewnić Zespołowi niezbędną stabilność w ramach iteracji, Cel Sprintu zmieniany być nie może i Developerzy mają prawo odmówić podjęcia prac, które jego osiągnięciu nie służą.

Pojawia się też trzeci sposób, w jaki Cel Sprintu ułatwia działanie w Scrumie. Otóż jasne staje się, kiedy Product Owner może przerwać już rozpoczęty Sprint: wtedy, gdy uzgodniony w czasie Planowania Sprintu Cel już nie ma znaczenia i jego osiągnięcie jest zbędne. Przy czym nie chodzi tu o zmianę priorytetów – nie można przerwać Sprintu dlatego, że trzeba zacząć robić ważniejsze rzeczy, niż te już znajdujące się w realizacji. Chodzi o zaprzestanie działań na rzecz Celu Sprintu, który stał się nieaktualny i którego osiągnięcie nie przyniesie w związku z tym żadnej wartości. Przykładowo, jeśli budowana była aplikacja do obsługi wydarzenia, które zostało odwołane, to nie ma sensu jej kończyć. Inny przykład: jeśli produkt powstawał dla klienta, który zerwał nagle kontrakt, kontynuowanie prac może nie mieć sensu.

Prywatnie sądzę, że twórcy Scruma, czyniąc ustalenie Celu Sprintu obowiązkiem, chcieli w jeszcze jeden sposób pomóc Zespołom, choć akurat niekoniecznie zostało to ciepło przez niektóre z nich przyjęte. Otóż jeśli Backlog Produktu jest w kiepskiej kondycji i nie do końca wiadomo, dlaczego pewne rzeczy poszybowały w górę a inne w dół, zaczyna być trudno odpowiadać na pytania w rodzaju „po co to robimy?” lub „czemu akurat to jest ważne?”. Konieczność ustalenia jasnego Celu Sprintu ujawnia problem, który bez tego mógłby zostać zignorowany. A to daje szansę, że Backlog Produktu zostanie w końcu choć trochę udoskonalony.

Problem: brak spójności w Backlogu Produktu

Czy zdarza się wam, że w czasie Planowania Sprintu patrzycie na listę elementów Backlogu Produktu, które zostały podjęte do realizacji i drapiecie się po głowie, zadając sobie pytanie: „co łączy je wszystkie”? Jeśli tak, zapewne Backlog Produktu ułożony został w sposób niezapewniający choćby minimum spójności. Z czego może to wynikać?

Czym jest nasz produkt?

Jedną z przyczyn może być złe wykrojenie produktu z większej całości lub zgromadzenie w jednym Backlogu Produktu potrzeb związanych z kompletnie różnymi produktami. To powoduje, że elementy Backlogu będą ze sobą luźno powiązane lub tych związków nie będzie w ogóle. Faktycznie, ciężko wtedy mówić o klarownym Celu ich realizacji i rodzą się potworki klasy „zrobić to wszystko” jako odpowiedź na pytanie, co jest Celem Sprintu.

Jak sobie z tym poradzić? Cóż, zadbać o wyklarowanie najpierw definicji produktu lub produktów, a potem zbudować jeden sensowny Backlog lub wiele Backlogów, jeśli produkt nie jest jeden. W tym drugim przypadku, zamiast w jednej długiej iteracji pracować nad wszystkimi produktami naraz, Zespół powinien realizować krótsze Sprinty, każdy poświęcając zawsze jednemu produktowi i przełączając się między nimi (oraz ich Backlogami) na granicach iteracji. Tempo rozwijania tych produktów raczej od tego nie spadnie, a możliwe stanie się uzyskanie Backlogów z dużą (lub jakąkolwiek) spójnością i jakiekolwiek skupienie Zespołu w trakcie Sprintów na sensownym Celu.

Schyłek życia produktu

Czasami produkt jest dobrze zdefiniowany, a mimo to w jego Backlogu znaleźć możemy przysłowiowy groch z kapustą. To może być objaw, że produkt doszedł do fazy, w której tak naprawdę dokonujemy szeregu mało istotnych zmian, bo brak nam odwagi do zatrzymania dalszych prac nad nim. Duży rozrzut tematów, między którymi nie ma związku i brak jasnej odpowiedzi, dlaczego akurat je robimy, to sygnał, że być może… trzeba przestać je robić. Zająć się rozwojem innego produktu, gdzie przyniesie to realną wartość. I tylko wtedy, gdy pojawi się sensowna konieczność dokonania w starym produkcie większej zmiany, wrócić do prac nad nim – już bez trudu znajdując odpowiedź na pytanie „czemu to robimy?”.

Różne rodzaje spójności

Jeśli elementy Backlogu Produktu opisują komplementarne funkcjonalności, łączy je jakiś aspekt biznesowy, są elementami tej samej większej całości – wtedy mamy łatwo dostrzegalną spójność biznesową (niektórzy mówią też, że to spójność funkcjonalna). Idealna sprawa, ale nie zawsze możliwa do uzyskania. Przykładem takiej spójności może być lista wymagań związanych z jakimś serwisem internetowym, zaprezentowana poniżej:

  • Założenie nowego konta poprzez wypełnienie formularza
  • Zmiana automatycznie wygenerowanego hasła dostępu
  • Reset zapomnianego hasła
  • Edycja danych użytkownika
  • Zmiana adresu email, z którym związane jest konto użytkownika
  • Logowanie i wylogowywanie się

Co łączy te wymagania? Wszystkie dotyczą obsługi kont użytkownika i gdyby stało się tak, że będą realizowane w jednym Sprincie, to jego Celem mogłoby być np. „udostępnienie serwisu pierwszym użytkownikom, którzy będą mogli stworzyć w nim swoje konta”.

Bywa wszakże tak, że potrzebujemy wykonać jakieś zmiany w produkcie po to, by możliwe stało się wydanie nowej jego wersji – wtedy mówimy o spójności wydaniowej. Popatrzmy na listę wymagań poniżej (znów związaną z przykładowym serwisem internetowym):

  • Strona wymusza użycie certyfikatu SSL
  • W stopce strony umieszczony jest link do Polityki prywatności
  • W przeglądarce nieobsługującej JavaScriptu pojawia się informacja o wymogu jego włączenia
  • Walidacja zgodności ze standardami HTML5 i CSS3 kończy się bez błędów i ostrzeżeń
  • Tłumaczenia opisów formularza rejestracji na język czeski są kompletne

Z pozoru te wymagania są kompletnie różne, ale jeśli wiemy, że to są jedyne rzeczy, których brak, aby uruchomić czeską wersję naszej strony internetowej, to nagle pojawia się spójność, czyż nie? Cel Sprintu staje się oczywisty: „udostępnienie serwisu internetowego użytkownikom z Czech”.

Jeśli i taka spójność wydaniowa nie jest możliwa, można grupować zmiany dokonywane w jednej technologii, w jednym komponencie produktu, w jednym jego obszarze itd. W ten sposób pojawi się coś, co można by określić mianem spójności technologicznej (nazywanej też spójnością implementacyjną). I wtedy Cele Sprintu – już nie takie łatwe do ustalenia, ale wciąż lepsze niż „zrobić to wszystko” – mogą przybrać formę na przykład taką: „usunięcie z systemu centralnego banku obsługi nieużywanych metod płatności”.

Jest jeden istotny warunek zapewnienia, że spójność będzie dostrzegalna. Warunkiem tym jest przejrzystość Backlogu Produktu. Jeśli elementy coś łączy albo jest jeden powód, dla którego zostały zdefiniowane – to powinno dać się zobaczyć. Product Ownerzy mają różne sposoby, by to robić, wiele narzędzi ma gotowe mechanizmy. Oznaczanie elementów tagami, ustalenie specyficznej konwencji nazewniczej nazw elementów Backlogu, możliwość wyświetlania listy pogrupowanej po tematach biznesowych… to tylko kilka opcji.

Przy czym nie można się zachłysnąć możliwościami, jakie dają współczesne narzędzia, w których utrzymywane są dziś Backlogi Produktu. Bardzo łatwo jest doprowadzić do sytuacji, w której każdy widzi inną zawartość lub kolejność elementów Backlogu, a wtedy nijak nie da się obronić tezy o jego przejrzystości. Efektem będzie chaos decyzyjny, a do tego żaden Product Owner nie może doprowadzić.

Problem: „bezcelowy” Sprint

Nieprzesadnie częstą sytuacją (na szczęście!) jest Sprint, w ramach którego Zespół realizuje wymagania, które nic nikomu nie dają, niczego nie umożliwiają, nie dają żadnej wiedzy ani wartości, a jedynie są etapem przejściowym na drodze do wytworzenia jakiejś większej całości. Ustalenie Celu Sprintu w tej sytuacji to prawdziwa droga przez mękę, a pomysł, by wziąć pod uwagę tę większą całość, też nie pomaga, bo wtedy Cel Sprintu w szeregu kolejnych iteracji byłby taki sam.

Znacie to? Jeśli tak jest, to waszym problemem nie jest Cel Sprintu, ale… zupełnie niezwinne działanie. Realizujecie klasyczne projekty w kamuflażu z elementów Scruma, bo iteracje służą wyłącznie do dzielenia realizacji jakiegoś planu kawałek po kawałku, a nie kreowaniu co Sprint wartości przyrostowo. Scrum wymagając ustalenia sensownego Celu Sprintu (czego nie sposób zrobić w takiej sytuacji), daje wam możliwość dostrzeżenia tego problemu.

No, chyba że Zespół pójdzie na łatwiznę i „rozwiąże” problem, ustalając Cel Sprintu następujący: „zrobić wszystko, co podjęte zostało do realizacji”.

„Zrobić wszystko”

A właściwie czemu taki Cel („zrobić wszystko”) miałby być zły? – pytają często uczestnicy szkoleń, które prowadzę. Cóż, nie jest zły, tylko zwyczajnie marny. Pokazuje bowiem, że nie mamy żadnej lepszej odpowiedzi na pytanie o powód, dla którego podejmujemy kosztowne i wymagające wysiłku działania. Ciężko zresztą takim Celem Sprintu wesprzeć się w podejmowaniu decyzji.

Jest marny jeszcze z innych powodów. Niespecjalnie motywuje do działania, a wystarczy nie zrealizować choćby jednego elementu podjętego z Backlogu Produktu do Sprintu i natychmiast staje się nieosiągalny.

Negocjowalny Cel Sprintu

Sensowny Cel Sprintu motywuje do działania i jednocześnie pozwala na zachowanie elastyczności (niezbędnej do naprawdę zwinnego działania). Popatrzmy raz jeszcze na wymagania z przykładu zaprezentowanego wcześniej:

  • Założenie nowego konta poprzez wypełnienie formularza
  • Zmiana automatycznie wygenerowanego hasła dostępu
  • Reset zapomnianego hasła
  • Edycja danych użytkownika
  • Zmiana adresu email, z którym związane jest konto użytkownika
  • Logowanie i wylogowywanie się

Jeśli Celem Sprintu jest „udostępnienie serwisu pierwszym użytkownikom, którzy będą mogli stworzyć w nim swoje konta”, Product Owner może po dyskusji Developerami uznać, że jest on osiągnięty nawet wtedy, gdy nie udało się zbudować mechanizmu zmiany adresu email przypisanego do konta. Ba, Cel ten – w ograniczonym zakresie – można uznać za osiągnięty nawet wtedy, gdy niemożliwe będzie również zresetowanie zapomnianego hasła i trzeba będzie pisać do administratora systemu, by zrobił to ręcznie.

Czy takie interpretowanie Celu Sprintu jest w ogóle dopuszczalne? Oczywiście, bo nie jest to żadna jego interpretacja. Celem nie jest przecież „mieć mechanizm resetu hasła” ani „funkcjonalność zmiany adresu email”, tylko udostępnienie serwisu użytkownikom. Czy będą oni w stanie założyć swe konta bez tych dwóch wspomnianych funkcjonalności? Jasne, że tak.

Dlatego zamiast o interpretowaniu Celu Sprintu lepiej w opisanej sytuacji mówić, iż Cel ten okazał się negocjowalny, mimo że jest jednocześnie bardzo specyficzny, czyli konkretnie wskazuje, po co odbywa się Sprint. Ta negocjowalność związana jest nie tyle ze zmianą Celu (bo ta nie następuje), co z elastycznością wyboru zakresu zmian w produkcie, jakie zostaną zrealizowane na drodze do jego osiągnięcia.

A drugi przykładowy Cel Sprintu, czyli „udostępnienie serwisu internetowego użytkownikom z Czech” i związane z nim wymagania?

  • Strona wymusza użycie certyfikatu SSL
  • W stopce strony umieszczony jest link do Polityki prywatności
  • W przeglądarce nieobsługującej JavaScriptu pojawia się informacja o wymogu jego włączenia
  • Walidacja zgodności ze standardami HTML5 i CSS3 kończy się bez błędów i ostrzeżeń
  • Tłumaczenia opisów formularza rejestracji na język czeski są kompletne

Można go uznać za osiągnięty mimo braku informacji o konieczności obsługi JavaScriptu, od biedy Product Owner może zaakceptować też rozwiązanie, które nie jest w pełni zgodne z HTML5 i CSS3, jeśli są tylko ostrzeżenia, ale nie ma błędów podczas walidacji. Znów: Cel jest specyficzny, ale negocjowalny.

„Zrobić wszystko” jako Cel daje niewiele możliwości takiego redefiniowania zakresu prac, jakie zostaną wykonane. Właściwie można to zrobić jedynie poprzez ich przypiłowanie, czyli rezygnację z realizacji części zmian już w trakcie Sprintu. Przy czym skoro Celem jest „zrobić wszystko”, to takie działanie jest de facto zmianą Celu, formalnie niedopuszczalną w Scrumie. Nie mówiąc już o tym, że odpiłowane kawałki wymagań będą musiały trafić do Backlogu Produktu (ciężko je będzie jakkolwiek sensownie zdefiniować, bo w praktyce będzie to opis niedoróbek i braków, jakie trzeba załatać…).

Problem: sposób realizacji Planowania Sprintu

Czasami nie udaje uniknąć problemów z ustalaniem Celu Sprintu nawet wtedy, gdy Backlog Produktu nie jest śmietnikiem na wymagania w agonalnej kondycji. Pomimo starań Product Ownera i pomagającego mu Scrum Mastera, mimo naprawdę dużego ogarnięcia i zaangażowania Developerów, gdy już sporządzona zostanie prognoza tego, co będzie realizowane w Sprincie, ciężko wymyślić jakikolwiek sensowny Cel. Musiałoby to być jakieś hasło bez znaczenia albo wspomniane wcześniej „zrobić wszystko”.

Skąd taki problem? Najczęściej przyczyna jest bardzo prozaiczna: Developerzy, dyskutując na bieżąco z Product Ownerem, zgarniają do Sprintu kolejne elementy z Backlogu Produktu, trzymając się ich kolejności. Wszak kluczem porządkowania elementów w Backlogu jest właśnie oczekiwana przez Product Ownera kolejność ich realizacji. Wszystko odbywa się więc zgodnie z wymogami Scruma, czyż nie? Niezupełnie.

Mity i nieporozumienia

Prawdą jest, że Developerzy nie mogą dowolnie wybierać elementów z Backlogu Produktu w trakcie Planowania Sprintu i powinni trzymać się kolejności, jaką ustalił Product Owner.

Prawdą jest też jednak, że Backlog Produktu to plan osiągnięcia Celu Produktu, jaki na chwilę obecną wydaje się Product Ownerowi najwłaściwszy. Co nie oznacza, że rzeczywiście jest dobry ani że w dyskusji z Developerami nie może zostać udoskonalony.

Planowanie Sprintu nie ma polegać na bezmyślnym zgarnianiu łopatą z góry Backlogu Produktu elementów w liczbie „ile wlezie”, ale – jak sama nazwa wskazuje – na zaplanowaniu Sprintu. Czyli ustaleniu, po co on się odbywa, a także co trzeba zrobić, by to osiągnąć oraz w jaki sposób Zespół to zrobi. Nie jest nigdzie w definicji Scruma określone, w jakiej kolejności Zespół ma te trzy rzeczy zdefiniować.

To zgarnianie z góry listy elementów nieuchronnie wiedzie do kłopotów z ustalenie Celu Sprintu, bo bez trudu zdarzy się, że są to rzeczy ze sobą niepowiązane. Zamiast zgarniać, lepiej wybierać elementy z Backlogu.

Plan wynikający z Celu Sprintu

Niech więc Planowanie Sprintu wygląda tak, że Product Owner wyjaśni, czym kierował się w trakcie porządkowania elementów Backlogu Produktu – dlaczego takie, a nie inne rzeczy znalazły się aktualnie na początku listy. Wyłoni się z tego prototyp Celu Sprintu, czyli propozycja Product Ownera, co mogłoby takim Celem być. O ile nie może on narzucić Celu Sprintu, bo ten ustala cały Zespół Scrum, ma prawo i być może nawet obowiązek jakiś Cel zaproponować.

Developerzy poszukają wtedy odpowiedzi na dwa pytania:

  1. Czego potrzeba do osiągnięcia zaproponowanego Celu Sprintu?
  2. Czy da się go osiągnąć przed końcem planowanego Sprintu?

Być może Backlog Produktu jest ułożony faktycznie tak, elementy z jego początku, realizowane po kolei, zaowocują uzyskaniem tego, co proponuje Product Owner i jest to w sam raz tyle pracy, ile Developerzy mogą wykonać w Sprincie.

A może trzeba będzie, aby zaproponowany Cel Sprintu osiągnąć, pozmieniać kolejność zaproponowaną przez Product Ownera (w końcu nie zawsze ma on świadomość zależności technicznych, o których w ramach Planowania Sprintu poinformują Developerzy). Product Owner może w dowolnym momencie zmienić kolejność i zawartość Backlogu – dlaczegóż miałby nie móc zrobić tego teraz?

Oczywiście będzie często tak, że proponowany Cel Sprintu jest zbyt ambitny. Co wtedy? Zespół Scrum (nie sam Product Owner ani nie sami Developerzy) poszukają wtedy innego Celu i powtórzą proces opisany powyżej. Niewykluczone, że takich iteracji przed zakończeniem Planowania Sprintu odbędzie się kilka. Ważne, że cały Zespół dąży wspólnie do tego, by nadać Sprintowi jak największy sens.

W tym modelu Planowania Sprintu nie zdarzy się, że Cel Sprintu będzie hasłem na odczepnego (przypominam, że rozważamy sytuację, że Backlog Produktu jest w dobrej kondycji). Nikt nie wpadnie też na pomysł, by Celem było „zrobić wszystko”. Czasami Cel Sprintu faktycznie obejmował będzie wszystkie podjęte do realizacji elementy Backlogu, częściej tylko niektóre z nich – ale to jest jak najbardziej typowa sytuacja w Scrumie. Te elementy, które nie są niezbędne do osiągnięcia Celu Sprintu, będą po prostu mniej priorytetowe i w krytycznej sytuacji nie zostaną zrealizowane (zakładam, że zdarzy się to wyjątkowo).

Zachęcam do takiego Planowania Sprintów, bo wtedy nie istnieje „problem z ustalaniem Celu Sprintu”, który z czegoś niepotrzebnego i kłopotliwego staje się punktem wyjścia do planowania iteracji.