Kiedy Sprint jest zakończony?
Dość często zdarza się, że zespół na koniec zwinnego Sprintu lub iteracji ma jeszcze niedokończone prace. Idealnie byłoby, gdyby zespół zawsze kończył każdy element Sprint Backlogu w trakcie Sprintu. Z różnych powodów nie zawsze tak się jednak dzieje. To prowadzi do kilku pytań, które omówię poniżej:
Co powinno się stać z danym elementem Product Backlogu?
Czy powinien zostać podzielony, czy przeniesiony do następnego Sprintu? Czy zespół powinien zaliczyć sobie punkty velocity za ukończone części historyjki?
Czy element jest nadal aktualny?
Gdy element Product Backlogu nie został ukończony na koniec Sprintu, powinien właściwie wrócić do Product Backlogu. Prace nigdy nie są automatycznie przenoszone z jednego Sprintu do następnego.
Może jestem w tym temacie nieco pedantyczny, ale chodzi mi o to, aby każdy Sprint zaczynał się od świadomej decyzji Product Ownera o tym, nad czym zespół powinien pracować. Oczywiście jest bardzo prawdopodobne, że Product Owner będzie chciał, aby zespół ukończył niedokończone prace z poprzedniego Sprintu w nowym Sprincie. Jednak powinna to być zawsze świadoma decyzja Product Ownera.
(Tylko jako uwaga: nie mówię, że powinieneś robić sobie nadmierną pracę, jeśli korzystasz z narzędzia, które by to zbytnio utrudniało. Mówię tylko, że praca nie jest automatycznie przenoszona do następnego Sprintu. Product Owner powinien zawsze decydować, czy praca jest nadal aktualna.)
Podzielić czy przenieść do następnego Sprintu?
Gdy Product Backlog nie mógł zostać w pełni ukończony, członkowie zespołu często zastanawiają się, czy zostawić element Product Backlogu takim, jakim jest (nawet jeśli część funkcjonalności jest już gotowa), czy przepisać go tak, by opisywał tylko brakującą część.
Przykład: Weźmy jako przykład zespół pracujący nad typową funkcją podglądu wydruku dla aplikacji desktopowej. Jeśli zespół ukończył wszystko poza możliwością przewijania stron, członkowie mogą albo zabrać oryginalną User Story do następnego Sprintu, albo napisać mniejszą historyjkę zastępczą: „Jako użytkownik chcę móc cofać strony podczas wyświetlania podglądu wydruku".
Jeśli historyjka zostanie ukończona w następnym Sprincie, sugerowałbym po prostu zostawić ją taką, jaka jest, i nie przepisywać jej. Wszyscy znają historyjkę w takiej formie, w jakiej jest napisana. Jeśli więc Product Owner nadal uważa ją za ważną, trafia do następnego Sprintu bez zmian.
Jeśli jednak pozostała praca ma zostać przesunięta na późniejszy Sprint, należy napisać nową historyjkę opisującą tylko niedokończoną część funkcjonalności.
Pamiętaj: Jeśli praca zostanie ukończona w następnym Sprincie, historyjka nie jest przepisywana.
Czy zespół dostaje punkty do velocity?
Lubię zajmować nieco konserwatywne stanowisko w kwestii velocity. Oznacza to, że zespół powinien otrzymywać punkty tylko za pracę, która jest naprawdę w pełni ukończona. Oznacza to:
Jeśli niedokończony element Product Backlogu jest przeniesiony do następnego Sprintu i tam ukończony, zespół nie powinien otrzymywać za niego punktów w pierwotnym Sprincie. Zamiast tego zespół otrzymuje wszystkie punkty za historyjkę w Sprincie, w którym praca jest faktycznie ukończona. Ponieważ jestem zwolennikiem pracy ze średnią velocity, to się wyrównuje i nie ma ryzyka, że velocity zostanie zawyżone.
Inaczej jest jednak, gdy zespół dzieli historyjkę i zwraca pozostałą pracę do Product Backlogu, by zająć się nią później. W takim przypadku zespół dostaje punkty za wykonaną pracę. Członkowie zespołu muszą wtedy jak najlepiej oszacować, ile punktów warta jest wykonana praca. Nawet jeśli cała historyjka nie jest jeszcze gotowa, możliwe, że zespół otrzyma wszystkie pierwotne punkty za historyjkę, bo może się okazać, że historyjka była większa niż zakładano. Nie powinno się to zdarzać ciągle, ale od czasu do czasu jest to w porządku.
Podsumowanie: Zawsze szukaj przyczyny
Gdy na koniec Sprintu pozostają niedokończone prace, zespół powinien zawsze znaleźć czas na retrospektywie, by ustalić, czy przyczyna była możliwa do uniknięcia. Czasem to po prostu pech lub zły timing – na przykład gdy członek zespołu zachoruje lub pojawi się problem, którego nie można było przewidzieć na początku Sprintu. Zawsze warto jednak zastanowić się, jaka była przyczyna i jak można temu zapobiec w przyszłości.
Tekst pochodzi z bloga Mike'a Cohna i został przetłumaczony przez nas na język polski.
User Stories, Epics, Themes
Wyjaśniamy różnicę między tymi elementami.
=>User Stories, Epics, Themes
Tworzenie produktu
Od pomysłu do realizacji za pomocą Product Vision Board.
=>Product Vision Board
Czym są Story Points?
Dowiedz się, gdzie możesz poprawić estymację swojego zespołu.
=>Czym są Story Points?
