Czwarty temat na Planowaniu Sprintu 

Dziś zajmiemy się scrumowym tematem, o którym nikt nigdy nie słyszał, bo wymyśliliśmy go sami. A co! Poznajcie czwartą część Planowania Sprintu, na której ustalimy jedną niezwykle ważną rzecz – co będziemy pokazywać na Sprint Review. A zaraz postaramy się uzasadnić po co.

Planowanie i Review

Większość z Was wie, że Planowanie Sprintu to wydarzenie Scrum, które ma trzy części. W podlinkowanym tekście opisaliśmy je tak szczegółowo, jak się tylko da. W skrócie, te tematy możemy sprowadzić do prostych pytań: „Po co?”, „Co?” oraz „Jak?”. Jeżeli mamy sprawnie działający proces refinementu, to nie powinno być problemu, żeby uporać się z tym nawet w 45 minut.

Wiemy, też, że Sprint Review to nie demo! Stary Scrum Guide, w odróżnieniu od wersji z 2020 roku, wymieniał osiem aspektów tego wydarzenia. I tylko jednym z nich była demonstracja Przyrostu dokonywana przez Developerów. W aktualnym podręczniku w dalszym ciągu znajdziemy bardzo istotne dla naszego dzisiejszego tematu zdania.

„Scrum Team prezentuje rezultaty swojej pracy kluczowym interesariuszom, omawiane są także postępy w dążeniu do Celu Produktu. (…) Sprint Review to spotkanie robocze, a Scrum Team powinien unikać ograniczania go jedynie do prezentacji.”

Po pierwsze i najważniejsze, pamiętajmy, że wspomniana prezentacja jest tylko i wyłącznie jednym z wielu elementów Przeglądu Sprintu. Od zawsze zresztą uważam, że lepszą nazwą byłby „Przegląd Produktu”, bo przecież patrzymy tam na to, co już wydarzyło (Przyrost, Cel Sprintu) oraz co będzie się działo (Product Backlog, Cel Produktu). Nawet pomimo tego uważam, że są takie sytuacje, gdzie bardzo nam się przydadzą ustalenia odnośnie tego, czym będziemy się chcieli pochwalić. I to im wcześniej się one zadzieją, tym lepiej.

Czwarta część Planowania Sprintu

Może nie powinniśmy tego nazywać „czwartą częścią”, ale „czwartym tematem”. Chodzi ni mniej, ni więcej o to, aby już na Planowaniu Sprintu ustalić sobie, co będziemy pokazywać interesariuszom na Sprint Review. To jest tylko i wyłącznie mały detal do ustalenia. Nawet pomimo tego, że w poprzednich akapitach starałem się podkreślić, że nie to jest w Review najważniejsze, uważam, że warto.

Z jakiegoś powodu ta część Przeglądu Sprintu zawsze powoduje najwięcej kontrowersji. Nikt nie ma problemu z tym, żeby powiedzieć co się udało zrobić, a czego nie. Większość osób też jest w stanie spokojnie mówić o tym, jakie trudności napotkał zespół i jak sobie z nimi poradził. Ba, nawet bez większego stresu potrafimy mówić o tym, co poszło nie tak i dlaczego nie wszystko dojechało. A już pokazanie Backlogu Produktu i snucie wizji na przyszłe Sprinty to już pestka.

Gdy jednak trzeba ustalić kto pokaże i co to będzie, to na wiele osób pada blady strach. Niektórzy wręcz próbują posiłkować się nagrywaniem filmików, które potem na Review można odtworzyć i pokazać (co wcale nie jest kiepskim pomysłem, ale o tym innym razem). Inni biorą chorobowe, a ostatnio mają problem z łączem, Teamsami czy VPN-em. To oczywiście żarty, ale jakoś tak jest, że mało kto chce pokazywać. Co dziwne, bo w większości przypadków jest to całkiem miłe chwalenie się dobrze wykonaną robotą. Skąd więc ta niechęć?

Czasami ludzie unikają demonstracji efektów prac na Review z obawy przed krytyką, bądź ze strachu przed „publicznymi” występami. Bywają też zupełnie inne powody, jak brak poczucia odpowiedzialności za produkt. Tu już duża rola Product Ownera i przede wszytkim Scrum Mastera, żeby stworzyli właściwe środowisko, gdzie nikt się niczego i nikogo nie boi, a wręcz otrzymuje potrzebne wsparcie.

Dobre i złe scrumowe praktyki

Jest wiele rzeczy, które robi się ucząc kogoś właściwych nawyków, a które tak naprawdę wcale nie są dobre w długim terminie. Możemy tutaj chociażby przywołać kółka doczepiane do rowerów dla dzieci. Są one idealnym przykładem na coś, co robimy celowo źle, żeby móc nauczyć się robić coś dobrze.

Idealny Scrumowy przykład to Definition of Ready – zestaw reguł, który mówi nam, kiedy w ogóle możemy rozważać jakieś wymaganie na Planowaniu. Nie jest to nam potrzebne, jeżeli wszystko działa jak należy, ale bardzo może się przydać, gdy mamy problemy z Product Ownerem dorzucającym w ostatniej chwili nowe wymagania do Backlogu Produktu. Definition of Ready maskuje problem, ale go nie rozwiązuje, chociaż jako rozwiązanie doraźne i tymczasowe często się sprawdza.

W przypadku problemów z określaniem Celu Sprintu, niską wartością wymagań, tym, że „nie da się niczym pochwalić” oraz brakiem chętnych na zaprezentowanie się na Review – spróbujmy zacząć planować „co chcemy pokazać” właśnie na Sprint Planningu. Może i nie jest to eleganckie rozwiązanie, ale zmusi nas do zastanowienia się nad tym, co biznesowego dowozimy, jaką to ma wartość, czy wymagania zostały dobrze podzielone. W gratisie bardzo często dostaniemy też jasno sprecyzowany Cel Sprintu, z którym też bywa wiele problemów.

Niezależnie od dziedziny, nie patrzmy na doświadczonych ekspertów i nie próbować odtwarzać ich działań, jeżeli sami dopiero zaczynamy. To co robią zawodowcy na torze wcale nam nie pomoże w nauce jazdy samochodem czy motocyklem. Stawiając pierwsze kroki skupiamy się na czymś zupełnie innym niż potem, gdy jesteśmy średnio-zaawansowani bądź biegli. Oczywiście, najlepiej byłoby od razu uczyć się wszystko robić profesjonalnie, ale paradoksalnie może nam to zająć więcej czasu, nie mówiąc już o potencjalnym zniechęceniu się.

Jeśli więc macie problem z tym, co pokazać na tej krótkiej części Sprint Review, zacznijcie to określać na Planowaniu Sprintu. A jak już stanie się to dla wszystkich naturalne, to pewnie nawet nie trzeba będzie tego z góry ustalać.