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:
- pokazuje sens tego co robimy, nie robimy tego tylko dla szpanu i zabawy 😁
- 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)
- 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:
- Historyjki są proste i krótkie – niech Twój opis też taki będzie
- Z takich opisów będą korzystały też osoby nietechniczne w Twoim zespole (i jego otoczeniu)
- Lepiej inspirować do dyskusji, a nie zamykać tematu
- Napisz co chcesz zrobić, ale jeszcze ważniejsze dlaczego chcesz to zrobić
- 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”.