Najczęstsze błędy popełniane przy pisaniu User Story

W podejściu agile takim jak Scrum wymagania definiujemy na ogół w postaci User Story. Prosta forma, która ma adresować oczekiwania i potrzeby użytkowników często zespołom przysparza dużo problemów w implementacji. Szczególnie dużo błędów popełniają oczywiście zespoły dopiero zaczynające swoją przygodę na szkoleniach agile. Często błędy nie zostają wychwycone i skorygowane co prowadzi do złej opinii o metodykach zwinnych i zupełnie niepotrzebnego szukania obejść lub tworzenia hybryd ze stary podejściem. Dobra User Story ma kompozycję składającą się z trzech składników:

• Jako (konkretny użytkownik systemu)
• chcę… (pożądana cecha lub problem, który trzeba rozwiązać)
• bo wtedy/ponieważ… (korzyść płynąca z ukończenia story)
• Warunki Satysfakcji (Szczegóły dodane w formie testów akceptacyjnych)

Każdy z tych składników jest ważny i istotny w zrozumieniu wymagania.

User Story dla Usera/Użytkownika

Przykład: “Jako użytkownik chciałbym, żeby aplikacja umożliwiała zarządzanie ogłoszeniami, bo wtedy będę mógł usuwać nieaktualne i błędne ogłoszenia.” Problem: Taka Story jest zbyt ogólna. Kim jest nasz tajemniczy użytkownik i co on rozumie przez zarządzanie ogłoszeniami? Czy to jest administrator portalu, który chce mieć możliwość wyświetlania wszystkich ogłoszeń i ich moderacji lub czyszczenia bazy? Czy to jest ogłoszeniodawca prywatny, który chce mieć możliwość wyświetlania listy swoich aktywnych ogłoszeń i ich usuwania, kiedy przestają już być aktualne? Jak widać z punktu widzenia różnych rol czy person w systemie taka potrzeba może być różnie rozumiana.

User Story dla Product Ownera

Przykład: “Jako Product Owner chciałbym, żeby system pozwalał na usuwanie ogłoszeń, bo wtedy użytkownicy będą mieli możliwość usuwania ogłoszeń.” Problem: User Story nie może być pisane z punktu widzenia Product Ownera, ponieważ to nie on ma korzystać z systemu i to nie on ma potrzeby, które system powinien zaspokoić. W User Story pokazanej przykładzie nadal brakuje prawdziwej potrzeby użytkownika i typu użytkownika czy też roli jaką on pełni w systemie.

User Story dla Dewelopera

Przykład: “Jako deweloper chciałbym, żeby na środowisku produkcyjnym była zainstalowana 64-bitowa wersja Javy, bo wtedy w pełni wykorzystamy nowe maszyny.” Problem: To jest można powiedzieć sztandarowy przykład User Story dotyczącej aspektów technicznych i często należącej do zbioru “technical debt”, czyli rzeczy, które trzeba wykonać z technicznego punktu widzenia ale nie dostarczają żadnych nowych funkcjonalności. Podobnie może wyglądać User Story dla refactoringu. I po raz kolejny elementami brakującymi tutaj jest korzyść dla użytkownika, rola lub rodzaj użytkownika i problem, który Story ma rozwiązać. Nie oznacza to, że tego typu potrzeby, czy wymagania nie mogą być zapisane jako User Story i maja być rozwiązywane w inny sposób. Można po prostu zapisać takie wymaganie z punktu widzenia korzyści dla użytkownika systemu. Na przykład: “Jako komercyjny użytkownik systemu chciałbym, żeby system działał szybciej, bo wtedy będę mógł wykonać więcej zapytań i szybciej znaleźć interesujące mnie ogłoszenia.” W warunkach satysfakcji umieszczamy przynajmniej “System odpowiada na przeciętne zapytanie w czasie poniżej 5 sekund.” I jednym z zadań w tej Story będzie: “Zainstaluj 64bitową wersję Javy.”

Brak powodu w User Story

Przykład: “Jako komercyjny użytkownik chciałbym mieć możliwość filtrowania ogłoszeń.” Problem: Nie wiadomo po co temu użytkownikowi możliwość filtrowania. Nie wiadomo też w jaki sposób ma się odbywać filtrowanie i po jakich kryteriach i przede wszystkim nie wiadomo co użytkownik rozumie przez filtrowanie. Co użytkownik chciałby osiągnąć?

Brak Acceptance Criteria/Warunków Satysfakcji w User Story

Przykład: Tutaj można wziąć za przykład jedną z User Story pokazanych w poprzednich przykładach. Problem: Jeżeli nie ma Warunków Satysfakcji, Story jest zdana na porażkę. Jest tutaj kilka powodów. Zadania deweloperskie mogą zostać źle zaplanowane. Story może nie przejść testów albo Przypadki Testowe nie będą odpowiadały faktycznej potrzebie, więc tak na prawdę zostanie przetestowane coś innego niż powinno. W czasie pozyskiwania Warunków Satysfakcji od użytkownika czy to w czasie trwania iteracji, Sprintu czy podczas Review może się okazać, że Story powinna być odrzucona lub oszacowanie było kompletnie nie poprawne i trzeba ta User Story ponownie zaplanować.