Warning: A non-numeric value encountered in /home/customer/www/iminno.com/public_html/wp-content/themes/marketing-expert/header.php on line 10
User story - 6 rzeczy, które musisz wiedzieć - I'm inno! Innowacje
Blog Własna firma Zarządzanie

6 rzeczy, które musisz wiedzieć, zanim zaczniesz pisać User Story.

zespół podczas tworzenia user story

Jak powiedział Albert Einstein: „Jeśli nie potrafisz wyjaśnić czegoś w prosty sposób – to znaczy, że niewystarczająco to rozumiesz.” Zatem zacznijmy od podstaw. W przystępny sposób wytłumaczę, czym jest poprawnie zdefiniowane User Story i jak wiele możemy stracić, jeśli posługujemy się tą bronią nieumiejętnie. 😉

User Story – jak je tworzyć?

W metodologii Agile User Stories są zazwyczaj najmniejszymi jednostkami pracy. Celem każdego User Story jest dostarczenie określonej wartości zdefiniowanemu interesariuszowi (zazwyczaj jest nim nasz klient lub użytkownik). Zwróć uwagę, że naszym użytkownikiem wcale nie musi być ktoś z zewnątrz organizacji. Może nim być np. nasz współpracownik, dział customer support czy analityk, który polega na narzędziach i danych dostarczonych przez Twój zespół.

Prawidłowe User Story, to zazwyczaj jedno zdanie, które powinno być napisane możliwie prostym i zrozumiałym językiem oraz wskazywać oczekiwany rezultat. Ważne by nie wchodzić zbytnio w szczegóły, bo członek zespołu, który będzie odpowiedzialny za wykonanie zadania będzie czerpać przyjemność z wyboru najlepszej drogi do osiągnięcia tego celu.

W jakim celu stosuje się User Story?

User Story opisuje, co zespół powinien stworzyć, jakie funkcjonalności i szczegóły zawrzeć, na czym się skupić podczas tworzenia produktu oraz jakie wartości przekazać. US jest również używana do zdefiniowania Backlog produktu. Jest to element, który pozwala ustalić kolejność wykonywanych zadań. Najbardziej istotne kwestie, które powinny być zrobione jako pierwsze mają ustalony największy priorytet.

5 rad, które pomogą Ci napisać świetne User Story.

Czy dobrze spisane User Stories są kluczem do sukcesu? Tak, bo na pewno redukują ilość nieporozumień, a więc i stresu. Wielkorotnie widziałem sytuacje, gdy niedoświadczone zespoły poświęcały cały sprint na dowiezienie funkcjonalności, która była niewłaściwa. Dlaczego dochodziło do takich sytuacji? Ktoś się spieszył i nie przyłożył się do prawidłowego spisania user story i tragedia gotowa. 😉 Jak uniknąć takich sytuacji i prawidłowo spisywać user stories?

1. Odbiorca jest najważniejszy, więc skup się na nim.

Aby przesłanie User Story dobrze zadziałało trzeba zrozumieć użytkownika i wartość jaką chce otrzymać. Dobre User Stories zawsze wchodzą w umysł klienta i pomagają spełnić jego oczekiwania. Sprawiają, że tworzony produkt będzie miał dokładnie takie funkcjonalności, jakich potrzeba. Pomocne są rozmowy i wywiady oraz dokładne wsłuchiwanie się w potrzeby.

2. Persona – klucz do sukcesu dobrego User Story.

Jest to przede wszystkim sposób na wejście w skórę innej osoby. Polega na stworzeniu profilu potencjalnego klienta wraz z opisem jego zainteresowań, cech oraz celem, jaki chce osiągnąć. Jeśli nie wiesz kim są Twoi użytkownicy i jaki problem chcą rozwiązać, wówczas nie jest możliwe napisanie dobrych US. Jeśli angielski nie jest Ci straszny, polecam Ci krótki i bardzo dobry filmik opisujący, jak stworzyć User Persona.

3. Prostota jest podstawą, więc trzymaj się jej.

Warto trzymać się najprostszego wzoru User Stories, aby nie zagłębiać się w zbędne szczegóły. Zwięzłość przy tworzeniu Story jest bardzo ważna. Kiedy skupiamy się na zbyt dużej liczbie funkcjonalności, aby zaspokoić nawet najmniej istotne potrzeby klientów nasz produkt może przybrać zupełnie inną formę, niż byśmy tego oczekwiali. Zatem minimalizm jest tutaj kluczowy. Poniżej przedstawiam wzór, którego warto używać.

Jako <persona>, chcę <cel>, ponieważ <potrzeba, którą chcemy zaspokoić>.

As a <type of user>, I want <goal> so that I <receive benefit>

4. Epics – nie bój się ich tworzyć.

Epic w metodologii Agile to opis oczekiwań kliena, który jest bardzo obszerny. Nie może zatem zostać bezpośrednio przekazany do zespołu developerskiego, w celu stworzenia końcowego produktu. Konieczne jest podzielnie go na mniejsze części, które są nazywane User Stories. Można więc powiedzieć, że Epic składa się z wielu User Stories. Zazwyczaj Epic nie jest możliwy do dostarczenia w jednym sprincie, bo po prostu reprezentuje bardziej złożone moduły produktu lub funkcjonalności

Po co je tworzyć? Epics są pomocne w zorganizowani pracy oraz ustaleniu hierarchii. Dzięki podzieleniu Epic w mniejsze User Stories zadania będą bardziej czytelne i zrozumiałe, a projekt zostanie szybciej wykonany.

5. Stwórz kryteria akceptacji.

Kryteria akceptacji określają co ma zostać zrobione. Pozwalają nam zdecydować, czy produkt zmierza w dobrym kierunku i czy dany etap można uznać za zakończony. Pomaga zaoszczędzić czas, w momencie, kiedy okaże się, że zespół projektowy zboczył z prawidłowych torów podczas tworzenia poszczególnych elementów.  

6. Używaj karteczek.

Używanie małych, kolorowych kartek przy pisaniu User Story ma wiele plusów. Przede wszystkim dzięki nim możemy spełnić najważniejszą cechę – zwięzłość. Na niezbyt dużej powierzchni nie ma wiele miejsca do pisania, dlatego powstałe User Stories nie będą zbyt długie. Takie kartki mogą być swobodnie grupowane na stoliku, czy tablicy. Kolejną zaletą jest współpraca zespołowa. Takie spotkania integrują zespół i tworzą dobrą atmosferę w pracy.

Nie bez powodu kolorowych karteczek używa się w brainstoringu. Przy takiej formie tworzenia mogą powstać naprawdę wartościowe US.

You may also like
Ile wart jest człowiek w gospodarce opartej na wiedzy?
Google - praca marzeń
Dlaczego każdy z nas chciałby pracować w Google?

Najwyższą formą docenienia jest lajk! ;)

Help spread the word. You're awesome for doing it! Dziękuje!