Skip to content

Optymalna długość Sprintu

Długość iteracji w Scrumie (Sprint) jest ograniczona do jednego miesiąca kalendarzowego. Chociaż w najnowszej wersji Scrum Guide’a nie ma określonego minimalnego czasu trwania Sprintu, to przyjmuje się, że krótsze niż jeden tydzień mogą być nieefektywne. Jak określić optymalną długość Sprintu?

Długość Sprintu powinna być określana na podstawie akceptowalnego poziomu ryzyka z jednej strony i czasu potrzebnego zespołowi na wytworzenie czegoś ukończonego z drugiej. Poziom ryzyka zależy od złożoności środowiska, w jakim pracujemy i horyzontu planowania.

Czynniki składające się na złożoność środowiska to: wymagania (ich znajomość i zmienność, co ma odzwierciedlenie w Backlogu Produktu i jego dynamice); technologia (nowa czy dobrze znana itd.); i ludzie (wielkość zespołu, zgranie, doświadczenie i poziom umiejętności, różnorodność specjalizacji itd.).

Jeśli więc mamy np. początek projektu, kiedy w wymaganiach jest dużo niewiadomych, często się zmieniają, Zespół Deweloperski jest liczny (np. 6-9 osób), świeżo skompletowany i do tego pracuje w nowej technologii, której nie zna, to mamy do czynienia z bardzo złożonym środowiskiem. Obranie więc 30-dniowego horyzontu planowania w takiej sytuacji spowoduje prawdopodobnie to, że poziom ryzyka będzie nie do przyjęcia. Chcąc go ograniczyć można redukować złożoność albo skracać horyzont planowania.

Oczywiście redukując i skracając do minimum możemy dojść do sytuacji, kiedy taki „zespół” nie będzie w stanie niczego wytworzyć. To ta druga strona, determinująca minimalną długość iteracji.

Tak więc to wszystko zależy od bardzo wielu czynników i nie ma prostej odpowiedzi na pytanie o optymalną długość Sprintu, chociaż ogólne wzorce można spróbować określić:

  • Dla krótkiego projektu (np. 2-miesięcznego) lepsze będą krótkie iteracje (np. 1-2 tygodniowe), bo długich (miesięcznych) będzie po prostu za mało i będziemy mieli zbyt mało okazji do inspekcji i adaptacji. W długich projektach można zaryzykować dłuższe iteracje, bo krótkie mogą okazać się zbędnym narzutem organizacyjnym.
  • Jeżeli mamy do czynienia z mało zaangażowanym klientem, lepsze mogą być znowu krótsze iteracje, bo zmusi go to do częstszych kontaktów z zespołem. Z zaangażowanym, ulokowanym w pobliżu zespołu Właścicielem Produktu umiejącym wykorzystywać Scrum w swojej pracy, można spróbować dłuższych.
  • Dla świeżych i niedoświadczonych zespołów znowu lepsze mogą być krótsze iteracje, żeby zespół nauczył się wytwarzać coś małego ale ukończonego. Długie iteracje to zbyt duże ryzyko, że więcej czasu i pracy się zmarnuje. O miesięczne Sprinty może się pokusić zgrany zespół wyjadaczy.
  • Jeżeli wymagania są słabo znane albo uczymy się nowej technologii, może być potrzeba wprowadzania częstszych zmian i szybszego uzyskiwania informacji zwrotnej, a więc krótsze iteracje. Stabilny, dobrze przygotowany Backlog Produktu, oraz technologia, z którą czujemy się komfortowo — można dłuższe.

Ważne jest, żeby zdawać sobie sprawę z tych wszystkich czynników i przy określaniu długości Sprintu brać je wszystkie pod uwagę, a najlepiej długość określać empirycznie, tj. wypróbowując różne „ustawienia”, pamiętając jednocześnie, że zbyt częste zmiany „ustawień” to znowu zwiększanie złożoności.

Categories: Sprint.

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.