Jako Scrum Master i trener Agile codziennie mam do czynienia z problemami wynikającymi z braku zrozumienia podstawowych zasad Scruma. Dla dobra zarówno klientów, jak i członków zespołów deweloperskich warto rozprawić się z najpopularniejszymi mitami na temat planowania w Scrumie.Jako Scrum Master i trener Agile codziennie mam do czynienia z problemami wynikającymi z braku zrozumienia podstawowych zasad Scruma. Dla dobra zarówno klientów, jak i członków zespołów deweloperskich warto rozprawić się z najpopularniejszymi mitami na temat planowania w Scrumie.

Mit 1. Estymacja równa się zobowiązaniu

Project managerowie, którzy nie mają doświadczenia w tworzeniu oprogramowania w Agile, ale za to pracowali według metodyk tradycyjnych (np. waterfall), często mylą estymację ze zobowiązaniem do wykonania danej pracy. Oto na czym polega różnica między tymi dwoma pojęciami. Estymacja mówi, ile czasu zespół sądzi, że spędzi na wykonaniu danego zadania. Dopiero podczas ustalania celu sprintu zespół zobowiązuje się do wykonania danego zadania. Określa w ten sposób, jaką część pracy obiecuje dostarczyć jako przyrost w ramach tego sprintu.

Mit 2. Określenie celu sprintu nie jest obowiązkowe

Ustalenie celu sprintu jest kluczowe dla jego powodzenia. Z kilku powodów. Po pierwsze, cel określa tę część pracy, do wykonania której zobowiązał się zespół. Po drugie, znając cel, można potem ocenić, czy sprint zakończył się sukcesem. I po trzecie, określony cel stanowi dla zespołu punkt odniesienia, zwłaszcza gdy sprawy przestają toczyć się według planu.

Mit 3. Nie można modyfikować backlogu po zaplanowaniu sprintu

Backlog sprintu to plan, zgodnie z którym zespół zamierza osiągnąć cel sprintu. W miarę jak dochodzą nowe dane o projekcie, produkcie i wymaganiach, plan ten trzeba modyfikować i dostosować go tak, by cel sprintu mógł zostać osiągnięty. Zespół (i nikt poza nim) może dokonywać zmian w backlogu, aby osiągnąć założony cel.

Mit 4. Można przewidzieć wszystkie zadania w ramach sprintu już podczas planowania

Podstawowe prawo w projektach software’owych mówi: „Zmiany będą”. Ani zespół ani Product Owner nie mogą przewidzieć wszystkich możliwych opcji przed lub w trakcie planowania sprintu. Taka potrzeba pojawia się, gdy zespół analizuje plan i zdobywa kolejne dane o tym, jaką pracę musi wykonać, aby osiągnąć cel sprintu.

Mit 5. Pracę przydziela się podczas planowania sprintu

Reagowanie na zmiany to podstawa Scruma i Agile. Jeśli każdy członek zespołu ma zadania przydzielone na etapie planowania, nie będzie w stanie reagować na zmiany. Jeśli nieoczekiwanie pojawia się nowe zadanie, lub któryś członek zespołu pracuje mniej wydajnie, nie można elastycznie podzielić pracy między pozostałe osoby. W rezultacie cel sprintu nie zostanie osiągnięty.

Mit 6. Zespół deweloperski nie musi przygotowywać się do planowania

To dość powszechna i bardzo szkodliwa praktyka, że dopiero na planowaniu sprintu zespół poznaje user stories, których stworzenia Product Owner oczekuje na koniec tego sprintu. Zespół proszony jest o szybką estymację i nie ma możliwości zagłębienia się w problem. W rezultacie w czasie trwania sprintu, kiedy wychodzą na jaw nieznane wcześniej aspekty user stories, trzeba wprowadzać drastyczne zmiany.

Mit 7. Cały backlog sprintu musi zostać w całości zdekomponowany podczas planowania sprintu

Równie częstą praktyką jest dzielenie całego backloga sprintu na mniejsze zadania i estymowanie każdego z nich oddzielnie. Według zwolenników tego podejścia pozwala to maksymalnie wykorzystać pojemność backloga bez jej przekraczania. Jednak wadą tego rozwiązania jest to, że potem nie ma możliwości wprowadzania żadnych zmian czy poprawek. Nie chodzi też tylko o gołą wartość, ale także o odczucie zespołu do czego mogą się zobowiązać.

Mit 8. Celem przeprowadzenia estymacji pozostałych do zrobienia zadań jest wyznaczenie ilości czasu do zakończenia projektu

Dla sukcesu każdego projektu ważne jest, żeby oszacować, ile pracy pozostało do zrobienia. Jednak estymacje wykonywane zgodnie z zasadami Agile wnoszą znacznie większą wartość niż tylko określenie przedziału czasu, w jakim projekt lub wybrana funkcjonalność zostaną zakończone.Podczas planowania odbywa się wiele rozmów między zespołem deweloperskim a Product Ownerem. Mogą oni dzięki temu zidentyfikować obszary wymagające większej uwagi lub dotychczas pominięte. Estymacja zadań i user stories to również doskonały sposób na to, by członkowie zespołu poznali i zrozumieli wszystkie kwestie tak samo.

Mit 9. Product Ownera może zastąpić dokładna dokumentacja

Obecność Product Ownera jest absolutnie konieczna podczas planowania sprintu. Powodów jest kilka. Po pierwsze, najskuteczniejszą metoda komunikacji jest rozmowa twarzą w twarz. W wielu przypadkach spisana dokumentacja projektu może być interpretowana na wiele różnych sposobów. Zadaniem Product Ownera jest wyjaśnić wszelkie pojawiające się wątpliwości. Po drugie, nawet w najlepiej sporządzonej dokumentacji mógł zostać pominięty jeden mały szczegół. Zazwyczaj to właśnie Product Owner jest osobą, która może doprecyzować kwestie z nim związane i podjąć stosowne decyzje.

Mit 10. Istnieje idealny, uniwersalny rozmiar dla User Story 

Prawda jest taka, że nie ma. Każdy zespół deweloperski jest inny. Każdy projekt jest inny. Technologia, doświadczenie zespołu, wiedza i wiele innych szczegółów składających się na specyfikę projektu ma znaczenie.

Istnieją dwie zasady dotyczące user stories:

  1. User story być na tyle mała, żeby mogła być dostarczona w ramach sprintu.
  2. Musi stanowić wartość biznesową.
Coach, mentor and Team Leader. Certified .NET developer, Agile enthusiast and Machine Learning specialist. In his free time ̶ avid scuba diver and fantasy books reader.