User story — czym są historyjki użytkownika i dlaczego warto z nich korzystać?

Adam
Adam
CEO & Co-founder

Proste, ale niezwykle przydatne historyjki użytkownika są świetnym narzędziem do tworzenia opisu funkcjonalności, których oczekuje użytkownik. Czym dokładnie są historyjki i jak usprawniają pracę zespołu scrumowego? 

Historyjki użytkownika (z ang. user story) opierają się na prostym schemacie „kto?”, „co?” i „dlaczego?”, co znacznie ułatwia przygotowanie wymagań produktu. Po zapoznaniu się z  historyjkami użytkownika zespół wie, dlaczego buduje daną funkcjonalność, co buduje i jaką wartość ma dostarczyć.

We wczesnych fazach, historyjka użytkownika jest po prostu krótkim zdaniem, ale nie jest kompletna, dopóki nie zostaną zdefiniowane szczegóły i kryteria akceptacji. Odpowiednio zastosowana user story pozwoli więc na zrozumienie wymagań, co przełoży się na zadowolenia klienta

User story — definicja

Historyjka użytkownika jest schematem opisywania funkcjonalności z perspektywy użytkownika końcowego. Pokrótce opisuje typ użytkownika wchodzącego w interakcję z systemem, jego potrzeby i ich uzasadnienie, co ułatwia stworzenie uproszczonego opisu wymagania. Jej celem jest opisanie, w jaki sposób dana praca dostarczy klientowi określoną wartość.

Historyjki użytkownika ułatwiają planowanie i dyskusję w zespole i opierają się na szablonie:

Jako [typ użytkownika], chcę [dany cel], aby [powód].

Proste i krótkie zdania są więc wyjściową dla tworzenia product backlogu i planowania iteracji.

Historyjka powinna być tak skonstruowana, aby można ją było ukończyć w jednym sprincie. Warto jednak wspomnieć, że, user story może być pisane na różnych poziomach szczegółowości, dzięki czemu historyjki mogą być wykorzystywane do opisania dużej liczby funkcjonalności. Duże historie są więc dzielone na mniejsze historyjki użytkownika, które mogą być wykorzystane w kolejnych iteracjach. 

User story — przykłady i dobre praktyki

Bazując na wspomnianym wyżej schemacie, przykładem historyjki użytkownika może być poniższe zdanie: 

Jako użytkownik czatu chcę dołączać załączniki do rozmowy, aby móc przesyłać ważne dokumenty. 

lub

Jako administrator, chcę generować raport z aktywności użytkownika w danym okresie, aby lepiej zrozumieć jego zachowanie

Ważne więc, aby dokładnie określić użytkownika końcowego i uzasadnić jego potrzeby i wymagania. Może to być więc osoba korzystająca z czatu na stronie lub administrator danej platformy.

W każdym z powyższych przykładów mamy więc danego użytkownika, wchodzącego w interakcję z systemem, co pozwoli mu na realizację określonego celu i osiągnięcie konkretnych korzyści. 

Kolejnym krokiem jest podanie warunków brzegowych, czyli kryteriów akceptacjiważne, aby dla każdej historyjki użytkownika napisać osobne kryteria. Muszą one być dobrze rozumiane i uzgodnione przez zespół. Dzięki temu product owner będzie mógł potwierdzić, że historyjka spełnia swoją funkcję. Spisanie kryteriów akceptacji pozwoli też na uniknięcie nieporozumień.

Na przykład, dla historyjki użytkownika „Jako użytkownik portalu chcę ustawiać zdjęcie profilowe, aby móc uatrakcyjnić swoje konto.”, kryteria akceptacji mogą być następujące: 

  • zdjęcie powinno mieć format .jpg,
  • zdjęcie powinno mieć wymiary 400 × 400 pikseli,
  • użytkownik powinien mieć możliwość podglądu zdjęcia, 
  • dodawanie plików w innym formacie powinno być zablokowane. 

Przykładowe kryteria akceptacji znajdziesz również w jednym z naszych blog postów.

Dlaczego warto korzystać z historyjek użytkownika?

Wykorzystanie historyjek użytkownika to oszczędność czasu — nie musimy tworzyć szczegółowej specyfikacji. Dyskusja, jaka wywiązuje się na podstawie napisanych historyjek, pozwala też na szybsze przystąpienie do prac — osoby zaangażowane w projekt wiedzą, czego oczekuje klient, co znacznie ułatwia dostarczanie wysokiej jakości oprogramowania. 

Jakie jeszcze korzyści płyną ze stosowania historyjek użytkownika? 

  • Prosty i spójny format, pozwalający na wyczerpujące opisanie danej funkcjonalności. Wymusza to więc poprawne definiowanie wymagań i daje pewność, że zespół techniczny zrozumie opisane zadania i odpowiednio je wykona. 
  • Uniwersalny charakter — format do tworzenia historyjek użytkownika z powodzeniem można wykorzystywać zarówno do tworzenia dużych, jak i mniejszych elementów aplikacji. 
  • Mniejsze ryzyko pomyłek — historyjki użytkownika dają kontekst i ułatwiają programistom zrozumienie korzyści dla użytkownika i wartości biznesowej, płynącej z danego projektu. Zespół skupia się więc na prawdziwych potrzebach użytkowników, a nie na abstrakcyjnych funkcjonalnościach. 
  • Oszczędność czasu dzięki mniejszej liczbie wymaganych poprawek. Formuła historyjek użytkownika ułatwia uniknięcie zbyt wczesnego wprowadzania szczegółów do projektu, więc proces tworzenia aplikacji jest znacznie sprawniejszy. 

 

Wykorzystanie user story w danym projekcie znacznie usprawnia więc pracę całego zespołu, pod warunkiem jednak, że napiszemy je w odpowiedni sposób.

Głównym błędem jest niekorzystanie z formułki, przez co role danych użytkowników nie są odpowiednio określone, co powoduje szereg wątpliwości lub prowadzi do stworzenia niejasnych wymagań. Błędnym podejściem jest także zbyt wczesne dodawanie szczegółów i wymagań oraz pominięcie kryteriów akceptacji.
 

Podsumowanie

Historyjki użytkownika zachęcają zespół do krytycznego i kreatywnego myślenia, prowadzącego do osiągnięcia założonego celu i wartości, których oczekuje klient. Tworząc user story, zespół wchodzi w buty użytkownika, więc jest to doskonały sposób na sprawne i precyzyjne opisanie funkcjonalności. 

Podobne artykuły
18 lutego 2021
Jak powinna wyglądać profesjonalna specyfikacja projektu informatycznego?
Rozpoczynając współpracę z software house’m, dobrze jest przekazać potencjalnemu partnerowi jak najwięcej kluczowych informacji dotyczących…
Czytaj więcej
22 kwietnia 2023
Środowisko AWS – o czym pamiętać przy wdrażaniu i skalowaniu?
Jeśli jesteś właścicielem startupu,  być może martwisz się skalowaniem swojej aplikacji wraz ze wzrostem jej…
Czytaj więcej
26 września 2022
Jak Design Sprint pomaga jasno zdefiniować założenia produktu?
„Design Sprint nadaje startupom supermoc: zanim podejmą jakiekolwiek kosztowne zobowiązania, mogą się szybko przenieść w…
Czytaj więcej