Cel Sprintu – jak to się robi

book

Wiedza | PROCES

Scrum jest frameworkiem. Czytając The Scrum Guide spodziewamy się otrzymać zestaw gotowych rozwiązań, a dostajemy ogólne ramy procesu przedstawione w krótkich żołnierskich słowach. I tak ma być. Tak stworzona elastyczność Scruma nie zawsze ułatwia nam zrozumienie, jak się do niego zabrać. Weźmy chociażby taki Cel Sprintu.

Czym jest Cel Sprintu?

Cel Sprintu pojawił się w Scrumie stosunkowo niedawno, bo dopiero gdzieś między 2011 a 2013 rokiem. Mimo to, jego echa słyszymy już u Mike’a Cohna w książce Agile Estimation and Planning w 2005 roku: “Cel iteracji […] jest ogólnym opisem tego, co [zespół] pragnie osiągnąć w nadchodzącej iteracji” [tłum. autora]. Scrum poszedł o krok dalej i definiuje Cel Sprintu jako pewne “założenie, które ma być spełnione w ramach Sprintu przez implementację wybranych elementów Backlogu Produktu” [oficjalne polskie tłumaczenie The Scrum Guide]. Ma to stanowić wskazówkę dla Zespołu Deweloperskiego, w którą stronę powinien się kierować tworząc Przyrost podczas nadchodzącego Sprintu.

 

W praktyce Cel Sprintu to jedno, może dwa zdania, które w prosty sposób podsumowują powód, dla którego Zespół Deweloperski przez cały Sprint tworzy Przyrost.

 

Cel Sprintu wypracowywany jest przez cały Zespół Scrumowy podczas Planowania Sprintu. To ważne, bo często spotykam się z przekonaniem, że Cel Sprintu narzuca Właściciel Produktu. Otóż Właściciel Produktu może, a wręcz powinien, pojawić się na Planowaniu Sprintu z pewnym określonym przez siebie życzeniem co do przyszłego Przyrostu. Konkretny Cel Sprintu tworzy się natomiast podczas rozmowy całego Zespołu Scrumowego – w końcu to Zespół Deweloperski decyduje podczas Planowania, ile elementów Backlogu Produktu będzie w stanie ukończyć w nadchodzącym Sprincie.

 

Przykład Celu Sprintu

W trakcie moich szkoleń dość często ilustruję, czym jest Cel Sprintu, krótką anegdotą o wizycie w restauracji.

Idziesz do restauracji na obiad. Wybierasz standardowo: zupę, drugie danie, surówkę, kompot, do tego ciasto i kawę. Polska klasyka. Twój “Sprint Backlog” przedstawia się zatem następująco:

  • zupa,
  • drugie,
  • surówka,
  • kompot,
  • ciasto,
  • kawa.

Ale jaki był cel Twojego przyjścia do restauracji? Co motywowało Cię do wejścia tutaj? NAJEŚĆ SIĘ! To oczywiste. Najedzenie się było Twoim “Celem Sprintu”.

Co ciekawe, nie każdy element w “Sprint Backlogu” wspiera realizację tego celu. Zupa, owszem, drugie danie również, możemy dyskutować o surówce. Ale kawa? Kompot? Bez nich cel i tak mógłby zostać zrealizowany.

Celem Sprintu (the Sprint Goal) nie jest zatem realizacja wszystkich zadań z Backlogu Sprintu. To może być w zasadzie celem każdego Sprintu (a sprint goal?). Cel Sprintu jest zgrabnym ujęciem tego, co Zespół Scrumowy chce osiągnąć tworząc Przyrost przez cały Sprint. Tak określony cel – w naszym przypadku: najeść się – pozostawia również pewne pole do manewru. Jeśli w połowie wizyty w restauracji okaże się, że nie stać Cię na wszystkie wybrane elementy, to część z nich możesz pominąć bez szkody dla Celu Sprintu.

 

Sprint kręci się wokół Celu Sprintu

Cel Sprintu nie doczekał się rangi osobnego artefaktu, ale czytając The Scrum Guide możemy odnieść wrażenie, że cały Sprint kręci się wokół Celu:

  • Podczas Sprintu nie wolno wprowadzać żadnych zmian, które zagrażałyby Celowi Sprintu.
  • Sprint może być przerwany, jeśli Cel Sprintu stanie się nieaktualny.
  • Zespół Deweloperski podczas Daily Scruma sprawdza, czy Cel Sprintu uda się osiągnąć.
  • Backlog Sprintu składa się z elementów Backlogu Produktu wybranych do Sprintu, planu dostarczenia Przyrostu i realizacji Celu Sprintu.
  • Przejrzysty Backlog Sprintu to taki, który między innymi pokazuje pracę zidentyfikowaną przez Zespół Deweloperski jako konieczną do osiągnięcia Celu Sprintu.

 

Czy Celu Sprintu może nie być?

Nie. Nie ma Celu Sprintu, nie ma Scruma. Dotyczy to zresztą każdego elementu tego frameworku.

 

Czy Cel Sprintu może być “niebiznesowy”?

Wszystko da się zrobić źle. I w zasadzie niczemu to nie przeszkadza, bo Scrum ma przecież wbudowany mechanizm ciągłego ulepszania: inspekcję i adaptację w warunkach pełnej przejrzystości procesu wytwórczego. To oznacza, że nawet najgorsze Cele Sprintu powinny z czasem ustępować miejsca dobrym.

 

Ken Schwaber i Jeff Sutherland podkreślają, że Celem Sprintu może stać się jakaś spójna funkcja tworzonego produktu, która wynika z wybranych do Sprintu elementów Backlogu Produktu. Innymi słowy wypadałoby, aby Cel Sprintu był “biznesowy”, a nie oderwany od tworzonego produktu. Wszak stanowi on drogowskaz dla Zespołu Deweloperskiego w Sprincie. Z drugiej strony, autorzy Scruma dopuszczają jednak możliwość, aby Celem Sprintu było jakiekolwiek inne spójne założenie, które pomoże Zespołowi Deweloperskiemu grać do jednej bramki w Sprincie. Jest to między innymi ukłon w kierunku zespołów, których produkt znajduje się w końcowej fazie swojego cyklu życia, a większość elementów Backlogu Produktu to zgłoszone defekty i drobne poprawki – w takiej sytuacji trudno o spójny cel wynikający wprost z listy zadań do zrobienia.

 

Czy zatem dobrym Celem Sprintu będzie “W tym Sprincie wreszcie wyjdziemy razem po pracy na piwo”? Taaaak, jeśli nic bardziej sensownego nie wynika z Backlogu Produktu. Jednak “biznesowy” cel ma wyraźny priorytet.

Powiązane artykuły, mogą Cię też zainteresować!

Ilustrowany Scrum Guide - darmowy e-book do ściągnięcia

Scrum: jest lekki, łatwy do zrozumienia i trudny w implementacji. Dlatego 7 listopada 2017 Jeff Sutherland i Ken Schwab...

Najważniejsze zmiany w Scrum Guide – spojrzenie subiektywne

Niejeden zespół boi się, że po zmianach w Scrum Guide już nie będzie zgodny ze Scrumem. A znacie jakikolwiek zespół, dzi...

Prosty przepis na udany produkt

Jesteś głową organizacji. Chcesz tworzyć świetne produkty. Scrum wydaje się rozsądnym wyborem. Przepis wydaje się pro...

Scrum Guide Wytłumaczony - Nieznośna lekkość Scrum Guide'a

Zważyłam Scrum Guide. Zważyłam Scrum Guide.Naprawdę. Wydrukowany jednostronnie na kolorowej drukarce laserowej, na pa...