Scrum umożliwia Product Ownerowi dokonywanie zmian w backlogu produktu w każdym momencie, gdy uzna, że kolejność elementów backlogu jest niewłaściwa, albo gdy trzeba usunąć jakieś wymaganie lub dodać nowe. Brak ograniczeń oznacza, że takich zmian Product Owner dokonać może tuż przed planowaniem sprintu, albo choćby podczas planowania.

Z drugiej strony zespół developerski ma ostatnie słowo jeśli chodzi o to, ile elementów (wymagań) podejmie z backlogu produktu do realizacji w sprincie. Product Owner ma prawo domagać się od developerów jak najwięcej, ale nie może im narzucić listy wymagań obszerniejszej niż to, co zespół prognozuje jako możliwe do ukończenia w ciągu jednej iteracji.

Co powinno stać się, gdy na szczycie backlogu Product Owner umieści wymaganie, którego zespół developerski nie widział wcześniej, które jest niezrozumiałe i prawdopodobnie zbyt duże, by dało się go zrealizować w sprint? Prerogatywy Product Ownera i developerów wydają się prowadzić do klinczu…

Drobna różnica między „ile” a „które”

W opisanej sytuacji wiele zespołów informuje Product Ownera, że nie może podjąć prac nad „wrzuconym w ostatniej chwili” wymaganiem, zanim nie podda go stosownej obróbce w czasie pielęgnacji backlogu. Argumentacją jest najczęściej prawo zespołu do decydowania o tym, jak wiele elementów pobierze z backlogu produktu do sprintu.

Rolą Scrum Mastera w takim przypadku jest przypomnienie, o czym tak naprawdę zespół decyduje. Nie o tym które wymagania zrealizuje, ale ile z nich, w kolejności ustalonej przez Product Ownera. Nie oznacza to, że zespół scrumowy nie może przeprowadzić dyskusji, po której ta kolejność się zmieni – jasne, że tak! Dopóki wszakże coś znajduje się na początku (na szczycie) listy, musi być realizowane jako pierwsze.

Nierównowaga ról w Scrumie?

Czasami spotykam się ze stwierdzeniem, że takie działanie świadczyć miałoby o nadrzędności potrzeb Product Ownera nad uprawnieniami zespołu developerskiego. Wyznający taki pogląd nie do końca rozumieją jak działa Scrum.

Należy bowiem przyjąć, że istnieją obiektywne przyczyny, dla których Product Owner dokonuje w ostatniej chwili tak kłopotliwej zmiany w backlogu, a które to zmiany – na stan wiedzy, jaką posiada – są w tym momencie najlepszym działaniem. Jeśli Scrum istotnie ma pozwalać reagować na zmienność i nieprzewidywalność otoczenia, to w sytuacji opisanej powyżej (a będącej emanacją tej zmienności i nieprzewidywalności) nie ma powodu do działania innego niż zazwyczaj. Developerzy nie mogą więc nagle zyskiwać prawa do narzucenia Product Ownerowi kształtu backlogu produktu.

Trzeba też pamiętać o tym, że każdy sprint to eksperyment: prognozowana jest wartość, jaką uda się osiągnąć po wykonaniu planowanych prac (jest to hipoteza eksperymentu), a sprint służy zweryfikowaniu tej prognozy. Rozwiązując złożone problemy i działając w złożonym środowisku, czasem trzeba liczyć się z zwiększonym ryzykiem, iż prognoza jest błędna (a po ludzku: że nie uda się zrealizować tego, co zaplanowano).

Na czym polega planowanie sprintu

Gdy zespół dobrze zna elementy na szczycie backlogu produktu, planowanie polega na ustaleniu, ile z nich uda się zrealizować i jakie konkretne działania trzeba podjąć, by zbudować działający produkt spełniający Definition of Done. Zawsze istnieje mniejszy lub większy poziom niepewności, są pytania, na które brak odpowiedzi, jakieś założenia. Planowanie polega więc na określeniu nie tylko jak zbudować produkt, ale też jak rozjaśnić wątpliwości, uzyskać niezbędne odpowiedzi, potwierdzić założenia.

A jeśli na szczycie backlogu znajdzie się nowe, nieznane wymaganie? Planowanie stanie się o tyle trudniejsze, że poziom niepewności jest wyższy a ilość pytań będzie większa, niż zazwyczaj. Ale poza tym zespół powinien działać tak samo, jak na każdym innym planowaniu.

Jak poradzić sobie z problemem

Przede wszystkim warto dokonać podziału kłopotliwego wymagania, w miarę możliwości wyłuskując z niego to, co powoduje, że jest tak pilne (powód, dla którego wylądowało na górze listy). Prawie zawsze da się to zrobić, bo przecież nikt, nawet Product Owner, nie miał jeszcze szansy na zrobienie tego wcześniej, na przykład w czasie pielęgnacji backlogu (wszak element został do niego dopiero co dopisany).

Warto też wesprzeć się ekspertami, jeśli tylko da się ich realnie ściągnąć na planowanie. Jeśli nie, plan realizacji powinien uwzględniać pracę z ekspertami, którzy już w czasie sprintu pomogą zespołowi doprecyzować szczegóły.

Kolejna kwestia to ułożenie planu realizacji tak, by najpierw wyeliminować największe niewiadome i ryzyka. Nie ma pewności, że wymaganie nie „wybuchnie” w rękach zespołu już w czasie sprintu, ale im wcześniej taki czarny scenariusz się ziści, tym większa jest szansa na poradzenie sobie ze skutkami nim iteracja dobiegnie końca.

Zdrowy rozsądek nakazuje zaplanować taki sprint nieco zachowawczo – czyli nie bierzmy wymagań „pod korek”, a raczej zostawmy nieco więcej czasu niezaalokowanego niż zwykle.

Aby uniknąć katastrofy już w czasie realizacji, zespół developerski powinien przyjąć zasadę, że mocno ogranicza ilość wymagań, które realizuje równocześnie, najlepiej do jednego (o ile to możliwe). Przyzwolenie na to, by z kłopotliwym i poniekąd ryzykownym elementem backlogu pracowało tylko kilku developerów, podczas gdy reszta teamu robi coś innego, jest proszeniem się o kłopoty. Prawie na pewno w trakcie prac ujawni się nowa, nieprzewidziana praca, i dobrze by było, aby od razu miał ją kto podjąć.

Kiedy zespół może odmówić realizacji wymagania

Jeśli uda się wykazać, że nie ma żadnych realnych możliwości ukończenia prac nad jakimś wymaganiem i zbudowania produktu zgodnie z Definition of Done, wtedy Product Owner nie ma wyjścia i musi przesunąć taki element backlogu w dół listy. Ale:

  • Brak wiedzy lub otwarte pytania be odpowiedzi to nie powód do odmowy realizacji wymagania. Można zaplanować zdobycie tej wiedzy i odpowiedzi.
  • Brak umiejętności w zespole to również nie powód do odmowy realizacji wymagania. Można zaplanować działania, które pozwolą uzyskać tą wiedzę lub wsparcie spoza zespołu.
  • Niespełnione zależności, o których wiadomo, też najczęściej nie są dobrym powodem, by wymagania nie podejmować do realizacji w sprincie. Można zaplanować sposób poradzenia sobie z zależnością (jej usunięcie, zaspokojenie, lub w ostateczności wytworzenie „zaślepki” pozwalającej na tymczasowe działanie produktu bez docelowego komponentu).

Warto tu podkreślić, że często nie da się w sposób obiektywny określić na planowaniu, czy rzeczywiście wymagania nie da się zrealizować. Jeśli dobrze się zastanowić, to jest tylko jeden taki przypadek: zależność, o której na pewno wiemy, że nie da się jej spełnić ani wyeliminować w czasie sprintu.

Skąd ten „brak elastyczności” w Scrumie?

Brak elastyczności jest pozorny – zespół developerski może przecież przekonać Product Ownera do zmiany kolejności w backlogu produktu. O ile, rzecz jasna, nie zamieni się to w przepychankę, która skonsumuje większość czasu przewidzianego na planowanie.

Ktoś może zapytać: no dobrze, ale czemu utrudniamy sobie życie aż tak? Czy naprawdę proces jest tak ważny? To dobre pytania, zasługujące na dobrą odpowiedź.

Oczywiście, proces jest ważny a jego przestrzeganie prowadzi do zachowania klarowności co do tego, kto w Scrumie za co odpowiada. Tak, jak pisałem wcześniej, gdyby Product Owner musiał przesuwać wymagania w backlogu za każdym razem, gdy zażąda tego zespół developerski, coraz trudniej byłoby odpowiedzieć na pytanie, kto właściwie decyduje o kolejności elementów na liście.

Dużo ważniejszy niż proces jest jednak fakt, że konieczność zmierzenia się z problemem, jaki powodują wpadające na ostatnią chwilę wymagania, zmusi cały zespół scrumowy do zastanowienia się nad przyczynami takiego stanu. Konsekwentne trzymanie się zasad spowoduje silny dyskomfort, który uniemożliwi zamiecenie problemu pod dywan. A to otwiera drogę do usprawnienia sposobu pracy z backlogiem produktu.

Gdy zespół scrumowy zacznie analizować przyczyny, może okazać się, że Product Owner „nie ogarnia” swojego produktu i jest zaskakiwany zmieniającymi się potrzebami interesariuszy. Albo że brak jasnej wizji produktu powoduje, że jego rozwój miota się w nieprzewidywalny sposób. Albo że organizacja nie rozumie jak działa Scrum i Agile, uniemożliwiając Product Ownerowi realne planowanie kolejnych etapów developmentu. Albo że potrzeba częstszej komunikacji z biznesem. Powodów może być dziesiątki. A ten najbardziej typowy to…

…kiepsko robiona pielęgnacja backlogu produktu

Proces pielęgnacji backlogu produktu nie powinien zajmować więcej niż 10% czasu zespołu developerskiego, natomiast Product Owner może i powinien się temu poświęcić w pełni. Gdy już w ramach retrospektywy sprintu zespół scrumowy zeskrobie warstwę pozornych przyczyn, dla których jest zaskakiwany nowymi wymaganiami pojawiającymi się w ostatniej chwili, okazuje się najczęściej, że zapobiec tomu może usprawnienie procesu pielęgnacji backlogu.

Te „nowe” wymagania nie biorą się bowiem z jakiegoś niedopowiedzianego Gdziebądzia, tylko są naturalną konsekwencją wcześniejszych zmian w produkcie. Zazwyczaj wiadomo o nich z pewnym wyprzedzeniem, bo są sygnalizowane choćby w dyskusji podczas przeglądzu sprintu. Jeśli developerzy rozmawiają z Product Ownerem o potencjalnych zmianach, jakie mogą w backlogu się pojawić, wpadające nowe duże wymagania nie są aż takim zaskoczeniem. Tak, może i nie było ich wcześniej w backlogu, ale cały zespół rozumie, dlaczego się tam znalazły, kiedy w końcu rzeczywiście się pojawią.