Czy cel sprintu w Scrumie jest opcjonalny?
Czy Cel Sprintu w Scrumie jest niezbędny, czy jedynie opcjonalny?
Niedawno miałem przyjemność uczestniczyć w meetupie lokalnej społeczności Agile prowadzonym przez trzech praktyków Scrum z solidnym stażem. Warsztat ten miał być możliwością przećwiczenia Scruma w praktyce.
Bardzo się cieszę, że część praktyczną poprzedzało krótkie ćwiczenie mające przypomnieć reguły Scrum. Bowiem sięganie do Scrum Guide jak najczęściej, to jeden z podstawowych obowiązków odpowiedzialnego Scrum Mastera.
Praktyka pracy w wielu polskich firmach pokazuje, jak często pracując rutynowo, zapominamy o regułach. Nie zastanawiamy się nad trzema filarami na których opiera się Scrum oraz wartościach które w tym frameworku są kluczowe.
Uczestnicy usłyszeli że Ramy Scruma tworzą Role, Wydarzenia i Artefakty, a pozostałe elementy frameworka są opcjonalne. A było wśród nich wielu młodych, mniej doświadczonych kolegów i koleżanek. Pozwolę się z tym stwierdzeniem nie zgodzić.
Cytując fragment jednego z ostatnich akapitów Scrum Guide:
Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Stosując jedynie część Scruma nie otrzymamy Scruma, raczej Zombie Scrum lub Kult Cargo. A w efekcie dziwimy się, dlaczego u nas ten Scrum nie działa? Nie działa, bo nie jest Scrumem.
Nie sposób odnieść się do całości wypowiedzi Agile Coachów prowadzących warsztat, oczywiście w zakresie teorii Scruma. Tym nie mniej, najbardziej utkwiło mi w pamięci iż Cel Sprintu (Sprint Goal) oraz Definicja Ukończenia (Definition of Done – DoD) to elementy opcjonalne Scrum.
Nie, nie i jeszcze raz nie!
I argumentem nie jest to, że tak jest napisane w Przewodniku po Scrumie.
Cel Sprintu
Sprint jest sercem Scruma, a Cel Sprintu ma dostarczać Zespołowi wskazówek po co tworzony jest Przyrost.
Cel sprintu tworzony jest podczas Planowania Sprintu przez cały Zespół Scrumowy. Moim zdaniem jest to niełatwe zadanie, a może nawet najtrudniejsze w całym planowaniu. Kreowanie celu sprintu to bardzo odpowiedzialne zadanie. Praca w Sprincie to nie odhaczanie kolejnych ticketów z Jiry. Bez Celu Sprintu Zespół może stracić motywację, zatracić sens swojej pracy.
Sprint kręci się wokół Celu Sprintu
Cel Sprintu nie ma jeszcze rangi osobnego artefaktu, wprowadzony został do Przewodnik po Scrumie dopiero ok. 2012 roku. Tym nie mniej, zaglądając do tego pierwotnego źródła wiedzy o Scrumie, odnosimy wrażenie, że cały Sprint kręci się wokół niego:
- Podczas Sprintu niedopuszczalne jest wprowadzanie zmian, które zagrażałyby Celowi Sprintu.
- Właściciel Produktu może przerwać Sprint, jeśli jego Cel przestanie być aktualny.
- Zespół Deweloperski w trakcie Codziennego Scruma sprawdza, czy Cel Sprintu uda się osiągnąć.
- Rejestr Sprintu składa się z elementów Rejestru Produktu wybranych do Sprintu, planu dostarczenia Przyrostu i realizacji Celu Sprintu.
- Przejrzysty Rejestr Sprintu to taki, który między innymi pokazuje pracę zidentyfikowaną przez Zespół Deweloperski, która jest niezbędna aby osiągnąć Celu Sprintu.
Definicja Ukończenia
Definicja “Ukończenia” (ang. Definition of Done, DoD) określa kiedy element Rejestru Produktu lub Przyrost uznajemy za “Ukończony”. Definicja ta musi być zrozumiała dla wszystkich uczestników procesu. Różne zespoły definiują ten stan w różny sposób. Dlatego kluczowe jest, aby wszyscy członkowie Zespołu rozumieli, co oznacza stwierdzenie że praca został ukończona.
Jest więc ona swoistą listą kontrolną, spisanym standardem. Dzięki niej, odhaczając kolejne jej elementy weryfikujemy, czy realizowany element Rejestru Sprintu jest już gotowy.
To właśnie klarowna i zrozumiała Definicja Ukończenia pomaga Zespołowi w określeniu ile i które elementy Rejestru Produktu można wybrać do realizacji w bieżącym Sprincie podczas Planowania Sprintu. Celem Sprintu jest bowiem dostarczenie Przyrostu – gotowej do wydania funkcjonalności zgodnej z aktualną definicją “Ukończenia”.
Definicja Przyrostu nie pozwala więc na to, aby Definicja Ukończenia była opcjonalna.
Przyrost funkcjonalności Produktu jest dostarczany w każdym Sprincie. Musi być on gotowy do użycia, aby Właściciel Produktu mógł zadecydować o jego wydaniu. Kiedy Definicja “Ukończenia” jest elementem przyjętych standardów lub wytycznych stosowanych przez organizację wytwarzająca oprogramowanie, wszystkie Zespoły Scrumowe muszą traktować je jako podstawę – niezbędne minimum i się jej podporządkować.
Jeżeli definicja “Ukończenia” nie jest elementem standardu organizacji, Zespół Deweloperski musi opracować definicję “Ukończenia” właściwą dla wytwarzanego przez Zespół Produktu. Gdy nad Produktem pracuje wiele Zespołów. muszą mieć one wspólną, uzgodnioną Definicję “Ukończenia”.
Każdy Przyrost jest rozszerzeniem wszystkich poprzednich Przyrostów. Jest on dokładnie przetestowany w celu zapewnienia iż wszystkie one działają razem jako całość.
Definicja “Ukończenia” zapewnia transparentność stanu każdego elementu Rejestru Sprintu. Transparentność jest jednym z filarów Scruma, ponieważ kiedy rozumiemy jaki jest stan obecny, to możemy podejmować odpowiednie decyzje — stosować empiryzm. Pozwala ona określić, jaką jeszcze pracę trzeba wykonać, aby Przyrost mógł zostać wydany na środowisko produkcyjne.
W miarę nabywania doświadczenia przez Zespoły Scrumowe, oczekuje się iż definicja “Ukończenia” zawierać będzie coraz bardziej rygorystyczne kryteria, coraz wyższej jakości. Nowe wersje tej definicji mogą ujawniać pracę niezbędną do wykonania na poprzednio “Ukończonych” Przyrostach.
Bibliografia:
Mike Cohn, “Agile Estimating and Planning”, Prentice Hall International, 2005
Paweł Feliński, “Cel Sprintu – jak to się robi“, Brass Willow, 2018
Krystian Kaczor, “Definition of Done – po co i jak stworzyć?“, QAgile, 2019
Ken Schwaber, Jeff Sutherland, “Scrum Guide“, Scrum.org, 2017
Saskia Vermeer-Ooms, “Zombie Scrum – how scary is it?“, Organize Agile, 2019
Wikipedia.org, “Kulty cargo“, npdst. “Encyklopedia“, PWN, 2019