Kategorie
Praktyka

User Stories. Co to jest? Czy warto zawracać sobie głowę?

Nasze backlogi wyglądają przeróżnie. Przykładowo czasem „taski” mają tylko tytuły i zero opisu – tłumaczymy, że ma być „lekko i zwinne”, a tak naprawdę nie chce nam się trochę i nie znamy metody jak pisać lepiej.

Kiedy indziej wrzucamy milion załączników i ścianę tekstu. Niełatwo odnaleźć „złoty środek”. Pomóc mogą w tym historyjki. Nie jest to lekarstwo na całe zło brzydkiego backlogu, ale przydatnych schemat, który pomaga zacząć: pisać o pomysłach, otwierać dyskusje i doprecyzowywać zespołowo szczegóły.

User Stories – co to jest?

Na początek trochę podstaw. User Stories, zwane historyjkami (poprawniej historyjkami użytkownika), to krótki i prosty opis jakiejś funkcji, którą chcesz zbudować, rozwinąć. Są napisane z perspektywy użytkownika – mówią nam o tym co on chce “mieć”, a co ważniejsze dlaczego tego potrzebuje.

Jeśli zatem, przykładowo, chcesz dla swoich użytkowników zbudować sekcję FAQ na stronie możesz w swoim Backlogu Produktu napisać “zbudujmy sekcję FAQ”, ale możesz też posłużyć się szablonem i napisać coś takiego:

Jako Mariola chcę mieć dostęp do FAQ, aby szybko znaleźć odpowiedzi na pytania dotyczące płatności i zwrotów.

Poprzednie zdanie to taki luźny przykład dla sklepu online. Co tu się stało? Zastosowaliśmy szablon historyjki użytkownika.

Jako <użytkownik> chcę <coś wykonać>, aby <jakiś powód, motywacja, dlaczego>.

Zwróć uwagę na szczegóły:

  • piszemy dla kogo coś zamierzamy zbudować
  • co w ogóle chcemy zbudować
  • i co najważniejsze – dlaczego chcemy to zrobić (jaki problem użytkownika to rozwiąże)

Spróbujmy jeszcze inne przykłady, np. blog o drewnie i stolarce:

Jako Michał chcę zapisać się na newsletter, aby być na bieżąco z nowymi poradami dot. metod obróbki drewna i narzędzi.

Proste? No pewnie!

Piszemy dla kogo, bo z reguły mamy swój “target”, jakiś typ docelowego użytkownika, dla którego tworzymy. W świecie rozwijania produktów nazywamy to “personą”. W powyższych przykładach Michał i Mariola mogą być imionami nadanymi naszym personom.

Opisywanie czym jest persona zajęłoby trochę miejsca, a ja chcę się skupić na historyjkach, więc jeśli chcesz dowiedzieć się więcej zapraszam pod ten link.

W takiej historyjce piszemy też co chcemy wykonać. Zwięźle, hasłowo – np. newsletter czy FAQ. Bez tego nie będziemy wiedzieli o czym w ogóle rozmawiamy.

No i najważniejsze – dlaczego w ogóle chcemy coś zrobić. Jaki problem użytkownika rozwiązujemy? To pomaga w kilku sprawach:

  1. pokazuje sens tego co robimy, nie robimy tego tylko dla szpanu i zabawy 😁
  2. kieruje nasze rozmowy na rozwiązywanie problemów, a nie wykonywanie gotowych pomysłów – moglibyśmy oczywiście po prostu powiedzieć “zróbcie ABC, które ma wyglądać tak, a nie inaczej”, ale takie podejście byłoby ograniczające (mniej pomysłów do wyboru, niekoniecznie najlepsze pomysły)
  3. deweloperzy, którzy będą budowali nasze rozwiązanie, będą lepiej rozumieli co ono ma rzeczywiście wykonać i do ostatniego momentu mogą (podczas dewelopmentu) poszukiwać lepszych rozwiązań.

Widzisz, historyjki pisane są inaczej niż klasyczne wymagania (ble, paskudne słowo!). To nie jest specyfikacja ani nic podobnego. Historyjki są proste, a ich celem jest dyskusja! Mają pobudzić kreatywność, rozmowy, a nie zamknąć temat. Traktuj je zatem jako narzędzie do inspiracji innych i wspólnego szukania rozwiązań, a nie szczegółowego opisywania jakiegoś pomysłu. To lepsze podejście niż opisywanie wymagań przez jedną osobę i wrzucania jej zespołowi do wykonania.

Nie jest też tak, że nie wolno dodać do takiej historyjki czegoś więcej. Możesz dodać więcej szczegółów (np. kryteria akceptacji, makiety itp.), najlepiej w wyniku rozmowy z zespołem, ale pamiętaj zawsze, że celem jest rozpocząć z prostym zdaniem, które zaprowadzi Was do głębszego zrozumienia problemu. Wszelkie szczegóły można zostawić na Backlog Refinement, dopisywać w formie komentarzy czy edytować istniejący opis.

User Stories nie dla mnie?

User Stories są najpopularniejsze, ale niektórym wydają się one sztuczne, “na siłę”, zespoły mają trudność z ich stosowaniem, “wbiciem się” w format. OK, nic na siłę! Po pierwsze są alternatywne formaty. Po drugie, zawsze można pisać po swojemu. Warto jednak wówczas pamiętać o kilku sprawach:

  1. Historyjki są proste i krótkie – niech Twój opis też taki będzie
  2. Z takich opisów będą korzystały też osoby nietechniczne w Twoim zespole (i jego otoczeniu)
  3. Lepiej inspirować do dyskusji, a nie zamykać tematu
  4. Napisz co chcesz zrobić, ale jeszcze ważniejsze dlaczego chcesz to zrobić
  5. Jako osoba dzieląca się pomysłem (np. Product Manager) nie pisz jak coś osiągnąć – detale zostaw deweloperom (czasem bywa tak, że opisujemy wszystko w szczegółach, także technicznie, nie tędy droga).

Zatem jeśli potrafisz spełnić powyższe punkty, to nie potrzebujesz szablonów. Eksperymentuj, próbuj po swojemu. A jeśli jednak potrzebujesz trochę nawigacji, a User Stories wydają się nadal trochę “niezbyt dla mnie”, to w kolejnych tekstach możesz poczytać o “Problem Stories” i “Job Stories”.

Nie przegap kolejnych fajnych postów i podcastów! Zapisz się na newsletter!

Przetwarzamy…
Udało się!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.