Nie przejmuj się formatem swoich historyjek użytkownika

Historyjki użytkownika są prawdopodobnie najbardziej popularną techniką w środowisku Agile do spisania funkcji czy błędów produktu. Z pozoru łatwe do zdefiniowania, w rzeczywistości mogą powodować wiele nieporozumień, jeżeli nie zostaną poprawnie określone i opowiedziane. Porad i zasad odnośnie tworzenia historyjek jest sporo. Czy istnieje jednak jedna idealna metoda? O tym dowiesz się poniżej. Zachęcam Cię również do przeczytania artykułu, jeżeli na co dzień wykorzystujesz inne techniki definiowania zadań dla zespołu.

Format Twoich papierkowych kartoników

Istnieje wiele porad dotyczących tworzenia poprawnych historyjek użytkownika. Jedną z nich jest zasada, że historyjki powinny być zgodne z cechami opisanymi za pomocą akronimu INVEST (po raz pierwszy akronimem posłużył się William Wake, autor książek Extreme Programming Language oraz Refactoring Workbook). Często wykorzystywany jest chociażby szablon „Jako <typ użytkownika> chcę <nazwa zadania> aby osiągnąć <cel>”. Powyższe porady i wiele innych sprowadzają się do tego, że wielu Product Managerów skupia się tylko i wyłącznie na stworzeniu historyjki zgodnej z zasadami, co prowadzi często do wielu nieporozumień. Niektórzy wręcz definitywnie twierdzą, że wartość biznesowa historyjki powinna być najważniejsza, inni na przykład, że „chcę” powinno być na samym początku. Wychodzę więc naprzeciw wszystkim tym osobom i podkreślam: Nie przejmuj się zawsze formatem swoich historyjek!

Istnieje kilka powodów, dla których nie powinieneś przejmować się strukturą historyjek, dopóki zawarłe(a)ś kluczowe elementy:

• Od tego w jaki sposób zapiszesz historyjkę, dużo ważniejsza jest rozmowa z zespołem, o której „karteczka z zadaniem” powinna Tobie tylko przypominać. O ile informacje w historyjce są prawdziwe, o tyle każdy format jest dobrym punktem do rozpoczęcia dyskusji.
• Nie ma jednoznacznego dowodu, że wybór konkretnej zasady tworzenia historyjki nad innym poprawi wydajność zespołu w znacznym stopniu. Pamiętaj również, że wszystkie porady/zasady niekoniecznie mogą się sprawdzić dla Ciebie.

Szablony są tylko standardem, które w Waszym projekcie mogą wyglądać zupełnie inaczej. Chociaż skorzystanie z zasady „Jako <typ użytkownika> chcę <nazwa zadania> aby osiągnąć <cel>” jest dobrym początkiem do rozpoczęcia dyskusji, nie trzymaj się konkretnego szablonu bez względu na okoliczności. W przeciwnym razie możesz skończyć z historyjkami typu: „Jako system, chcę raport…”. Zamiast bezskutecznego zastanawiania się nad wpasowaniem w szablon, zweryfikuj się czy dane osoby są rzeczywiście interesariuszami i chcą tego co zostało zdefiniowane.

Eksperyment

Zachęcam Cię gorąco do eksperymentowania ze swoimi user stories. Poniższe kroki możesz wykorzystać jako pomoc:

• Twórz historyjki na początku, ale szczegóły dodawaj później (np. podczas cyklicznych spotkań z zespołem, które wykorzystasz do omówienia kolejnych zadań)
• Nie zapisuj oczywistych rozwiązań i myśli
• Pomyśl o większej liczbie interesariuszy, którzy mogą być zainteresowani funkcją – zastanów się czy w takim przypadku nie warto podzielić historyjki na mniejsze części
• Używaj obrazków zamiast słów
• Zadawaj pytania

Zastosowanie różnych formatów może okazać się świetnym wyjściem, aby pobudzać dyskusję z zespołem lub spojrzeć na zadanie z innej perspektywy. W wielu wypadkach unikniesz także fałszywych historii. Alternatywnie możesz użyć całkowicie innej techniki opisu wymagań, jak np. przypadki użycia. Ta technika pomoże Ci bardziej w przypadku precyzyjnego opisu, na przykład, poprzez dodanie warunków wstępnych i wyjątków. Use Case’y sprawdzą się także lepiej w przypadku, kiedy nie masz możliwości zaangażowania zespołu (np. ze względu na pracę zdalną) w dyskusję czy w proces definiowania szczegółów.

Dobrym sposobem, aby poruszać dyskusję jest zapisywanie pytań, a nie rozwiązań. Skup się na problemie, wczuj się w użytkownika, zamiast na zastanawianiu się nad fizyczną implementacją.

Podsumowanie

Porady i szablony są niezwykle pomocne w definiowaniu zadań. Pamiętaj jednak, aby nie podążać ślepo w jednym kierunku, ponieważ może dać to odwrotny skutek do zamierzonego. Eksperymentuj z różnymi szablonami, zastanawiaj się nad pytaniami zamiast nad rozwiązaniami, a co najważniejsze – rozmawiaj. Dzięki tym prostym poradom Twoja praca będzie o wiele bardziej efektywna, a także pozwoli uniknąć Ci wielu nieporozumień!