User Story (Historyjka Użytkownika) jest jak album z wakacji...

Co to jest User Story?

+ BONUS: Odbierz praktyczne materiały o Agile i Scrumie.

User Story, czyli po polsku Historyjka Użytkownika jest nierozerwalnie związana z każdym zwinnym sposobem na pracę. Według definicji, Historyjki Użytkownika (zresztą jak sama nazwa wskazuje 🙂 ) są to proste i krótkie opisy funkcjonalności opowiadane z perspektywy osoby, która pragnie nowej możliwości — najczęściej klienta lub użytkownika systemu. Najczęściej są formułowane według wzorca wymyślonego w firmie Connextra:

JAKO <ktośtam> CHCIAŁBYM <cośtam> PO TO, ABY <ważny powód>

Oczywiście możesz je formułować zupełnie inaczej — to tylko jeden z punktów startowych i uważaj, żeby nie dać się wciągnąć w jedną ze świętych wojen „syntax wars” 🙂 – bo najważniejsze jest to, co się z Historiami robi.

Historie Użytkownika się opowiada

I jest to jedno z najważniejszych zadań Product Ownera. Nieopowiedziane Historie są jak album ze zdjęciami z wakacji — widzisz: Michał w krótkich portkach — znaczy, było ciepło, ale z kim był, gdzie był, czy było fajnie — możesz się jedynie domyślić. Nie spodziewaj się zatem cudów — jeśli tylko zapisałeś swoje Historyjki i wysłałeś do Zespołu — mnóstwa rzeczy będą musieli się domyślić i zwykle sporej części domyślą się inaczej, niż było w Twojej głowie. Dobre User Story musi prowokować do dyskusji — do zadawania pytań przez Zespół i do pełnego zrozumienia,  po co w ogóle to jest potrzebne — dopiero wtedy deweloperzy mogą znaleźć najlepsze rozwiązanie tego, JAK taką Historyjkę zaimplementować. Od chwili, gdy została zwięźle zapisana, Historyjka powinna być ciągle doskonalona (na przykład podczas Refinementu — o tym niezwykle ważnym procesie napiszę osobno!), a rezultat tych działań znajduje swoje odzwierciedlenie jako kryteria akceptacji. Zwykle im więcej wiadomo o tym, o czym opowiada — tym lepiej można estymować to, jak jest duża.

…a czym NIE jest User Story?

Pamiętaj, że Historyjka to NIE jest wymaganie! Nie jest to coś, co możesz wysłać do Zespołu i za jakiś czas przyjść i sprawdzić z tabelką, czy działa. Historyjka bez dyskusji, która się nad nią odbyła i bez ustalenia, po czym poznamy, że jest gotowa — jest absolutnie niekompletna. (O tym, czym są w Scrumie wymagania, czym jest Product Backlog i co warto w nim mieć — już wkrótce 🙂 )

User Story nie jest też lekiem na wszystko: Zespoły często się męczą i zżymają, bo ktoś był niedawno na szkoleniu i teraz każe im wszystko pisać „jako juzer”. Więc mamy „jako programista chcę podnieść wersję w pom.xml, żeby się kompilowało też innym programistom”. A teraz wyobraźcie sobie, że Product Owner (biznes) musi zdecydować o kolejności takich wpisów w Product Backlogu — myślę, że wybierze coś, co rozumie 🙂  Albo „jako product owner chcę, aby tekst w sekcji Kontakt był inny, bo ten, co jest — jest zły”. Dla mnie oczywiste jest, że w moim Product Backlogu mogą znaleźć się małe, techniczne zadania, w których jasnym jest, co jest do zrobienia. Dbam o to, by nie było ich zbyt dużo, ale też o to, żeby wiadomo było, dlaczego są niezbędne. Takie „taski” najczęściej trafiają do Backlogu w pośpiechu i, jeśli okazują się większym tematem — warto je rozpisać na Historyjki i przedyskutować. Ale jeśli to mała, dość oczywista rzecz (np. podmiana ikonki) – czasem szkoda czasu.

Pułapka Pobożnych Życzeń 🙂

Wyobraź sobie User Story: „Jako mieszkaniec Polski chcę płacić podatki po to, aby Polska rosła w siłę, a ludzie żyli dostatniej”. Dobra Historyjka? No niby dobra… A przynajmniej ułożona tak, jak nam mówili na szkoleniu. Tylko czy opowiada prawdziwą historię? Ja, jako mieszkaniec Polski chciałbym, owszem, żeby Polska rosła w siłę, ale wcale już z takim entuzjazmem nie odnoszę się do płacenia podatków — więc to chyba jest jednak historia kogoś innego… Podobna sytuacja może się zdarzyć w naszym Backlogu: „Jako użytkownik chcę się zarejestrować, aby móc korzystać z portalu”. Czy naprawdę to, o czym marzy każdy użytkownik to rejestracja na kolejnym portalu? Użytkownik chciałby szybko wyszukać lot. Albo kupić bilety do ZOO. Ale na pewno nie znowu zaczynać od żmudnego procesu rejestracji. Znacie serwis privnote.com ? Tam (prawdopodobnie) zostały napisane prawdziwe Historyjki, opisujące PRAWDZIWĄ potrzebę użytkowników i powstał serwis, którego można użyć w 10 sekund. Warto dbać o to, żeby w trakcie Refinementu przedyskutować i pozmieniać takie Pobożne-Życzenia-Kogoś-Innego w prawdziwe Historyjki Użytkownika. A jak mogłaby brzmieć ta z powyższego przykładu tak, żeby była prawdziwa i przynosiła prawdziwą wartość? Może np. tak: „jako marketingowiec chciałbym, żeby użytkownicy się rejestrowali w serwisie, po to, abym mógł potem ich śledzić i podnosić skuteczność sprzedaży” 🙂

Na wstęp — wystarczy. Jeśli szukasz więcej informacji o User Story, to zajrzyj tutaj: Jak tworzyć User Story? Wkrótce podyskutujemy sobie o tym, kiedy powstają Historyjki, jak powinny być duże, o pułapce Definition of Ready i kilku innych rzeczach — User Story to bardzo ważny temat w Agile!

Masz pytania? Lub może chcesz podyskutować na temat tego wpisu? Zapraszamy do naszej grupy Transformacje Agile na Facebooku.