Za dużo lub za mało pracy w Sprincie

Co zrobić jak mamy za dużo pracy w Sprincie i już wiemy, że się nie wyrobimy? A co, jeśli skończyły nam się wymagania i nie mamy co robić? Zadziwiająco, te pytania pojawiają się strasznie często, zarówno w początkujących jak i już doświadczonych zespołach.

 

Czym jest Sprint?

Zacznijmy od podstawowej sprawy. Sprint jest niczym innym, niż pewną siatką narzuconą na nasz kalendarz. Sprint trwa tyle, ile ma trwać i chociaż nie ma idealnej długości Sprintu, to jednak większość organizacji korzysta z dwutygodniowej rozdzielczości. Czyli co dwa tygodnie startujemy z nowym Sprintem, niezależnie od tego, co się w nim dzieje.

Takie wytłumaczenie jest czymś zupełnie dziwnym dla osób, które spotykają się z podejściem zwinnym po raz pierwszy. “Jak możemy skończyć Sprint, skoro nie wszystko zrobiliśmy?”, “Skoro skończyliśmy wszystko, co zaplanowaliśmy, to kończymy Sprint, prawda?” Otóż nie.

Na pewno nie wydłużamy, ani nie skracamy Sprintów. Tu powinna nastąpić kropka, bo to naprawdę jest aż tak proste. Sprint to wycinek naszego kalendarza o stałej długości. Staramy się w jego ramach dostarczyć jakąś wartość. Ponieważ nasze iteracje są stałej długości, to uczymy się coraz lepiej jak je właściwie zaplanować. Nie osiągniemy tego efektu zmieniając ich czas trwania.

A co, jak nam się skończą wymagania? Taka sytuacja w teorii może mieć miejsce, jeżeli zaplanowaliśmy się mocno poniżej naszych możliwości. Prawo Parkinsona jest jednak nieubłagane w takich przypadkach i ta sytuacja w praktyce miejsce ma bardzo rzadko. Jeżeli zaplanujemy o połowę mniej wymagań, niż jesteśmy w stanie zrealizować, to po prostu będziemy pracowali dwa razy wolniej i skończymy je pod koniec Sprintu.

Oczywiście, jeżeli wymagania nam się faktycznie skończyły i “nie mamy co robić”, to po prostu weźmiemy do realizacji kolejne, ale nadal Sprint skończy się wtedy, kiedy miał się skończyć. Analogicznie – jeżeli zaplanowaliśmy sobie za dużo, to po prostu niektórych rzeczy nie dowieziemy, a Sprint… skończy się wtedy, kiedy było to zaplanowane.

 

Zmiana długości Sprintu

Co do zasady, nigdy nie zmieniamy długości rozpoczętego Sprintu. Nieważne czy skończyły nam się wymagania, czy zabrakło nam rzeczy do roboty – Sprint trwa tyle, ile ma trwać. Jeżeli po długich debatach stwierdzimy, że być może będzie nam lepiej pracować w Sprintach dłuższych bądź krótszych, wtedy po prostu od pewnego momentu przechodzimy na iteracje o innej długości. Ale zmiana ta dokonuje się dopiero po zamknięciu jednego Sprintu.

Dla porządku należy przytoczyć tutaj jedną sytuację, w której możemy skrócić Sprint. A tak naprawdę, go przerwać, bo o tym mowa. Proces Scrum oferuje nam wyjście z sytuacji, w którym nasza praca w bieżącej iteracji straciła sens. W takim przypadku Product Owner (i tylko PO) może podjąć taką decyzję.

I znów, rozróżnijmy teorię od praktyki. W teorii takie przerwanie Sprintu jest dopuszczalne w sytuacji gdy Cel Sprintu się zdezaktualizuje. Ale Scrum Guide mówi też, że wszystkie zespoły pracujące na jednym Backlogu Produktu mają zsynchronizowane Sprinty. Z drugiej strony, jak przerwiemy Sprint w jednym z nich, to powinniśmy od razu wystartować kolejny o takiej samej długości. Czyli trochę nam się to nie spina.

W praktyce, nie dość, że przerwanie Sprintu jest wydarzeniem rzadkim i traumatycznym, to jeszcze dodatkowo najczęściej w takiej sytuacji po prostu kolejny Sprint się wydłuża tak, aby nadal były one zsynchronizowane pomiędzy zespołami. Oczywiście jest to fuj, niescrumowe, ale za to praktyczne.

 

To czym tak naprawdę jest Sprint?

Sprint to okres, w którym wykonujemy pracę i w którym uczymy się planować i pracować efektywnie. Oto i cała tajemnica tego pojęcia.

Co więc zrobić, jeżeli mamy za dużo lub za mało pracy w Sprincie? Absolutnie nic. Sprint zawsze skończy się wtedy, kiedy ma się skończyć, a my omówimy to co się udało zrobić na Sprint Review oraz porozmawiamy o procesie wytwórczym i tym, jak pracować lepiej na Sprint Retrospective. Tam też możemy dojść do wniosku, że nasze iteracje są zbyt długie lub zbyt krótkie. Ale taka decyzja zawsze powinna być dobrze przemyślana, bo efekty zobaczymy po kilku-kilkunastu Sprintach.

Przypomnijmy też dla porządku, że jak nam brakuje wymagań i nie mamy co robić, to zawsze coś do roboty sobie znajdziemy w backlogu. Najlepiej, żeby to były wymagania pochodzące ze szczytu naszej listy, uzgodnione i potwierdzone z Product Ownerem. W końcu to PO wie, co w danym momencie jest najbardziej priorytetowe. I jeżeli się okaże, że mamy “wolne moce”, to PO będzie wiedział jak je najefektywniej wykorzystać.

Analogicznie, jeżeli nie udało się czegoś dowieźć albo już w trakcie Sprintu wiemy, że nie wszystko zrealizujemy, to właśnie nasz Product Owner jest tą osobą, która podpowie nam, które wymagania można poświęcać na rzecz których.

A jeśli komuś jeszcze mało na temat iteracji i Sprintów, to zapraszamy do tekstu o Świątecznych Sprintach. Tam dowiecie się między innymi o tym, jak potraktować majówkę i inne długie weekendy.

Tomasz Dzierżek

18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Tomek - 7 maja 2021

Hej Tomek.

Jedna rzecz mnie zaskoczyła w Twoim tekście. Mianowicie ta: “Ale Scrum Guide mówi też, że wszystkie zespoły pracujące na jednym Backlogu Produktu mają zsynchronizowane Sprinty”.

Co masz tu na myśli?

Scrum Guide nic nie mówi o tym, że sprinty w zespołach pracujących na jednym PB mają mieć taką samą długość.

Pozdrawiam.

Reply
    Tomasz Dzierżek - 10 maja 2021

    Na pewno są o to pytania na egzaminach ze stajni Scrum.org. Wydaje mi się, że było też o tym jedno zdanie w starym Scrum Guide, ale to muszę go przejrzeć z lupą.

    Reply
Leave a Reply: