Jak opisywać “User story” w agile

W agile niezwykle popularnym narzędziem jest historyjka użytkownika. Zna ją każdy, kto w projektach korzysta z Jiry. „User story” często pada ofiarą bycia niedookreśloną, bo „przecież w agile nie trzeba dokładnie planować”. Jak dobrze zorganizowane zespoły zwinne opisują historyjkę? Przekonaj się w dalszej części tekstu.

Pozwolę sobie wrócić do przykładu z wpisu, w którym poznawałeś historyjkę. Znajdziesz go tutaj. Pisałam wtedy o flipcharcie:

Jako trener chcę, by flipchart miał kółka po to, bym mógł go przemieszczać po sali szkoleniowej.

Powyższe wymaganie może być różnie interpretowane. Czy, flipchart ma jeździć z jakąś prędkością? A może, ma poruszać się w jakiś określony sposób? Czy też, do przemieszczenia flipcharta chcę używać określonej siły?

Aby zapobiec nieporozumieniom, zespoły zarządzane agile opisują historyjkę dodając do niej: definition of done, use case, test case.

Use case

Zacznijmy od use case, czyli przypadku zastosowania. Wiem, że w firmach różnie się go opisuje. Spotkałam się z różnymi praktykami wśród Agile PMów. Mnie najbliższa jest ta, która mówi że celem use case jest podać przykładowe zastosowanie wymagania, które opisuję w historyjce. Mogłoby ono brzmieć w następujący sposób: „Często zdarza mi się zmieniać miejsca w sali, w której prowadzę szkolenie, w związku z tym przemieszczam się z flipchartem. Niestety, gdy ten nie ma kółek, a w zamian dysponuje nóżkami jak od sztalugi, mam problem z jego przeniesieniem. Po pierwsze jest duży, po drugie ciężki. Trudno przesunąć go po podłodze, równie trudno przenieść.”

Czy zauważyłeś jak pięknie przypadek użycia dookreśla po co użytkownik zgłosił wymaganie o kółkach? Okazuje się, że flipchart wcale nie musi mieć kółek, może być stworzony z lekkich materiałów i w ten sposób pozwolić się przenosić.

Definition of done

Załóżmy, że zespół przymocuje kółka do flipcharta i odda go w moje ręce –Agile Coach’a. Czy mam gwarancję, że przedmiot będzie dawał się przemieszczać? Nie do końca. Chciałabym mieć pewność, że flipchart został uprzednio przetestowany i dodatkowo odebrany przez osobę, która bada produkty pod kątem różnych atestów bezpieczeństwa. Zatem definition of done brzmi: flipchart można przemieszczać po sali określoną liczbę metrów, z użyciem określonej siły, przy określonej prędkości, co zostało przetestowane. I tu nasuwa się pytanie jak?

Test case

Na to pytanie odpowiedzą scenariusze testowe, w których opisujemy różne możliwości wykorzystania produktu, czy wybranej funkcjonalności. Tak! Przeczytałeś to, co przeczytałeś. W niektórych firmach, zarządzanych zgodnie z agile, to są przypadki użycia (use case), czyli różne możliwości zastosowania produktu, pod kątem których produkt ma być przetestowany. Wbrew pozorom jedno nie wyklucza się z drugim. Przypadki testowe będą określać różne możliwości, w jakie można wprowadzić flipchart w ruch. Podsumowując zatem, można robić to, pchając jego nóżki nogą, użyć rąk, czy też po prostu pchać go lub ciągnąć. Albo, trzymać go z góry lub z dołu.

Zasada 3 c

I ostatni ważny aspekt historyjki – zasada 3 c, czyli sposób omawiania każdego „user story” w agile:

1. Card – historyjka musi być zapisana na kartce.
2. Conversation – dyskusja wokół user story. Jak ją rozumiemy, czy trzeba ją podzielić na mniejsze albo jeszcze dookreślić?
3. Confirmation – na koniec potwierdzamy wszystkie ustalenia.

Zasada 3 c będzie stosowana podczas takich spotkań jak planowanie sprintu lub pielęgnacja rejestru produktu. 

Jeśli chciałbyś kontynuować  agile przygodę pod okiem fachowego  Agile Coach’a, to koniecznie sprawdź warsztat Biznesowy Scrum. Może akurat mamy zapisy w niższej cenie? Dowiesz się na stronie lub klikając na baner poniżej.

Poniżej możesz obejrzeć filmik z treścią wpisu. Jeśli chcesz otrzymać notatkę wizualną (ściągę) z nagrania, zapisz się do newslettera. Co tydzień wychodzą notatki z kolejnych sesji na żywo. Zapisz się tutaj.