Jest to najmniejszy kawałek funkcjonalności, które reprezentuje wartość dla użytkownika końcowego i może być dostarczona w trakcie trwania jednego sprintu.
Wydawałoby się, że stworzenie historyjki to nic trudnego, jednak niejednokrotnie spotykam się z historyjkami, którym brakuje podstawowych informacji. W związku z tym dziś (dla utrwalenia), krótko o tym co powinna zawierać dobra historyjka i jak się za to zabrać?
- Zdefiniuj swojego end usera. Kto będzie używał produktu?
- Sprecyzuj, czego chce użytkownik. Jakie rozwiązanie mogę mu zaoferować?
- Opisz korzyści. Co produkt dostarczy użytkownikowi?
- Dodaj kryteria akceptacji. Co spowoduje, że historyjka może być uznana za zrobioną?
Kilka dodatkowych wskazówek, które ułatwią Ci pracę:
- Zwizualizuj sobie użytkownika końcowego, postaw się na jego miejscu. Zawsze pisz wymagania z jego perspektywy.
- Unikaj dodawania zbyt wielu technicznych szczegółów zbyt wcześnie. To zespół deweloperski powinien zająć się określeniem technologii i dobraniem rozwiązań. Klient może jeszcze zmienić zdanie.
- Nie twórz zbyt dużych historyjek. Dobre praktyki wskazują na maksymalnie 13 story pointów – większe podziel.
- Upewnij się, że historyjka spełnia definition of done.
Ćwiczenie.
Spróbuj wykonać poniższe ćwiczenie:
AS A [Kim jest Twój end user = WHO?]
I WANT TO [Co chce end user = WHAT?]
SO THAT [Dlaczego user prosi o to = WHY?]
Metoda ta jest nazywa Three C’s – card, conversation, confirmation. Model został przedstawiony w roku 2001 przez Rona Jeffries’a.
Przykład historyjek dla stworzenia aplikacji taxi: [1]
JAKO kierowca, CHCĘ mieć możliwość zablokowania źle zachowujących się klientów, ABY więcej nie korzystali z moich usług.
JAKO pasażer, CHCĘ mieć możliwość podpięcia karty kredytowej, ABY płacić szybko i bezgotówkowo za przejazd.
JAKO kierowca, CHCĘ mieć możliwość dodania zdjęcia do profilu, ABY przyciągnąć więcej klientów.
JAKO pasażer, CHCĘ mieć możliwość oceny kierowcy, ABY eliminować niebezpiecznych kierowców.
Kto może tworzyć User Story?
Każdy, ale to Product Owner jest odpowiedzialny za backlog, w którym widnieją historyjki, najczęściej jest to jego zadanie.
Jaka powinna być user story?
Skąd wiemy, że przygotowana historyjka jest “dobra”? W trakcie jej tworzenia warto oprzeć się o proste zasady kryjące się pod akronimem INVEST, zaproponowanym przez Billa Wake’a.
- Independent (niezależna) — istnieje samodzielnie, może być zaimplementowana niezależnie od innych User Story.
- Negotiable (negocjowalna) — zespół deweloperski może doprecyzować szczegóły, ingerować w zakres.
- Valuable (wartościowa) — implementacja historyjki dostarczy wartość użytkownikowi.
- Estimable (szacowalna) — historyjka może być wyceniona w punktach przez zespół deweloperski, a następnie podzielona na mniejsze kawałki (zadania).
- Small (mała) — najlepiej, żeby mieściła się w jednym sprincie. Jej rozmiar nie powinien sprawiać problemów z oszacowaniem.
- Testable (testowalna) — każdą historyjkę powinno dać się przetestować i sprawdzić, czy spełnia wymagania użytkownika.
Pamiętajcie, dobrze przygotowana historyjka – zachęca do rozmowy, wywołuje dyskusję 😊
[1] https://stormotion.io/blog/how-to-write-a-good-user-story-with-examples-templates/