Co zrobić na koniec Sprintu z wymaganiem, które jest „prawie skończone” albo z takim, którego „działa połowa”? Co sprytniejsi zaproponują podzielenie US-a tuż przed końcem Sprintu, ale niestety mamy dla nich złe wieści…
Niedokończona praca w Sprincie
Podręcznikowe rozwiązanie problemu niezrealizowanych do końca zadań jest jedno. Jeżeli mówimy o Scrumie, to wymagania, które nie zostały ukończone w danym Sprincie wracają do Product Backlogu. Proste? W teorii.
W praktyce często zdarzają się próby naciągnięcia Kryteriów Akceptacji User Story bądź też zignorowania niektórych elementów Definition of Done. I w jednym, i w drugim przypadku niszczymy transparentność i malujemy trawę na zielono. Przy okazji tworzymy też dług technologiczny, który trzeba będzie spłacić. Bo przecież brakujące funkcjonalności bądź też wymagania niefunkcjonalne trzeba będzie kiedyś dorobić.
Jednym ze sprytnych, ale destruktywnych rozwiązań jest podejście pod tytułem „to odbierzmy to jak jest, a dodamy nowe wymaganie, w którym zawrzemy poprawki”. Ręka do góry, kto jest w stanie wskazać dziesięć problemów z tą propozycją?
Przede wszystkim nie powinniśmy pokazywać, że zrealizowaliśmy coś, czego nie skończyliśmy. Jeszcze ktoś przez przypadek może nam uwierzyć i to wdrożyć bądź zaplanować inne prace w oparciu o nasze „Almost Done„. Po drugie, zaburza to nasze Velocity, które pomaga nam określić ile jesteśmy w stanie zaplanować. Sami przed sobą udajemy, że zrobiliśmy więcej, niż faktycznie zostało zrealizowane.
Mam wymieniać dalej?
Dzielenie wymagań w trakcie Sprintu
Sprawa ma się jeszcze gorzej, jeżeli mamy do czynienia z dużymi wymaganiami, które nie dojechały (patrz: rozmiar User Story). Prędzej czy później, ktoś rzuci hasłem „To może podzielmy dane wymaganie na część, którą zrobiliśmy i to, co zostało?” W ten sposób teoretycznie moglibyśmy pokazać, że część zrobiliśmy, a część pozostała do realizacji.
Moim zdaniem, jest to jeszcze gorszy pomysł niż te z poprzednich akapitów. Dokonujemy sztucznego podziału post factum, bo coś nam nie wyszło. Jeżeli naszą intencją od początku była możliwość dopuszczenia do tego, że wykonamy tylko część danego zadania to powinniśmy byli je od razu podzielić na Planowaniu Sprintu. A być może nawet na refinemencie.
Przecież po to właśnie dzielimy wymagania! Jeżeli mamy do wprowadzenia 100 walidacji, to nie pakujmy ich wszystkich w jeden worek. Podzielmy je na walidacje związane z adresami, walidacje związane z innymi danymi kontaktowymi, itd. Wtedy, jeżeli jeden ze stu warunków nie zadziała, będziemy mogli pokazać, że co prawda jedno wymaganie nie zostało zrealizowane, ale reszta – tak.
Tylko dokonajmy tego podziału najpóźniej na Planowaniu Sprintu. Nasz plan jest sugestią dla innych zespołów, interesariuszy, Product Ownera odnośnie tego, czego mogą się spodziewać. Jeżeli później zaczniemy z niego „wykrajać” te kawałki, które nie działają i robić z nich jakieś „osobne US-y”, to trochę tak jakbyśmy gościowi, który spodziewa się dwudaniowego obiadu postawili przed nosem zupę i powiedzieli „zmieniliśmy pańskie zamówienie, po schabowego proszę przyjść jutro”.
No przecież nie na to się umawialiśmy.
Dzielenie User Stories
Dzieląc wymagania na to „co działa” i „co nie działa” napotkamy na kolejne problemy. Większość odruchowego dzielenia US-ów przebiega niezgodnie z zasadami sztuki. Mam tu na myśli przede wszystkim słynne kryteria INVEST, które powinny też być spełnione po podzieleniu. Najczęściej jednak w wyniku podziału wymagań lądujemy z koślawymi wymaganiami z dopiskiem „część pierwsza” i „część druga”.
Wydzielone, czy też podzielone wymagania, zapisywane w postaci User Stories, powinny być biznesowe. To znaczy, że powinny przynosić jakąś korzyść odbiorcy. Takiej korzyści nie daje nam „pół procesu” albo „kawałek formularza”, ale już da nam „możliwość złożenia wniosku bez żadnych walidacji”.
Jeżeli już coś robimy, to róbmy coś, czym potem będziemy mogli się pochwalić. Jak to zawsze mówię – wymagania, a nie zadania.
I oczywiście z nad klawiatury słyszę już te okrzyki pod tytułem „Nie wszystko da się podzielić na dwutygodniowe Sprinty!” Może i nie wszystko. Ale na pewno prawie wszystko, o ile właściwie do tego podejdziemy. Niestety, dzielenie wymagań na biznesowe kawałki funkcjonalności możliwe do zrealizowania w krótkich iteracjach jest czymś, czego prawie nikt nie uczy.
My też nie mamy na naszym blogu tekstu poświęconego dzieleniu User Stories i jeszcze pewnie długo takowy nie powstanie. Ta „wiedza tajemna” wymaga omówienia, zademonstrowania i przećwiczenia. Na szczęście mamy dla Was przygotowany warsztat pod tytułem „Wymagania w projektach agile„, w ramach którego dużo czasu spędzamy na wspólnym definiowaniu i dzieleniu wymagań.
Zapraszamy (na razie) na szkolenia zdalne, ale mamy nadzieję, że wkrótce też spotkamy się w salach. A kto wie, może w końcu popełnimy też jakiś dłuższy tekst o dzieleniu wymagań. Dajcie znać w komentarzach, z jakimi problemami się borykacie.
Rozumiem radę nie dzielić, zgadzam się, że dobre planowanie może pomóc ale w życiu zawsze pojawiają się takie scenariusze, które nas stawiają w sytuacji której nie przewidzieliśmy. Nie widzę wyjaśnienia co wtedy powinniśmy zrobić. Rozumiem natomiast, że niewykonane user story powinny przejść bez względu na ich wielkość do kolejnego sprintu a my w przyszłości powinniśmy postarać się lepiej planować lub tworzyć user story.
Jak najbardziej w takiej sytuacji powinniśmy pogodzić się z „porażką” i wyciągnąć z niej wnioski. Nie chcemy przecież zaciemniać rzeczywistości ani malować trawy na zielono. Chcieliśmy zrobić coś, nie zauważyliśmy, że da się to podzielić na mniejsze, trudno – zrobimy lepiej następnym razem. Pamiętajmy, że takie „podzielone na kolanie wymagania” bardzo często mają problemy jakościowe (bo co tak naprawdę testowaliśmy?) i zwykle nie spełniają Definition of Done.