User Story — co to jest i jak pisać historyjki użytkownika?

User stories są fundamentem Product Backlogu w Agile. Poznaj format, kryteria INVEST, jak pisać acceptance criteria i jak szacować story points.

Format user story

Jako [rola], chcę [cel/działanie], żeby [korzyść/wartość].

Dobry przykład:

"Jako zarejestrowany użytkownik, chcę zobaczyć historię swoich zamówień, żeby sprawdzić status dostawy bez kontaktowania się z obsługą klienta."

Zły — perspektywa systemu:

"Jako system, chcę zmodyfikować tabelę Orders, żeby dodać kolumnę status."

Zły — brak konkretnej korzyści:

"Jako użytkownik, chcę żeby aplikacja była szybka."

✓Perspektywa osoby, nie systemu — 'Jako użytkownik', nie 'Jako system'

✓Konkretna rola — 'Jako Admin firmy', nie 'Jako użytkownik'

✓Cel użytkownika, nie implementacja — 'zobaczyć historię', nie 'zmodyfikować bazę danych'

✓Jasna korzyść biznesowa — 'żeby' musi być wartością, nie technicznym opisem

Kryteria INVEST — dobra user story

Akronim INVEST to checklist jakości user story — każda dobra historyjka powinna spełniać wszystkie 6 kryteriów.

Independent

Niezależna — history powinna być możliwa do realizacji niezależnie od innych

Negotiable

Negocjowalna — szczegóły są do ustalenia, story to zaproszenie do rozmowy

Valuable

Wartościowa — dostarcza wartość użytkownikowi lub biznesowi

Estimable

Szacowalna — team jest w stanie oszacować nakład pracy

Small

Mała — mieszcząca się w jednym sprincie, max 8-13 story points

Testable

Testowalna — istnieje sposób na potwierdzenie że story jest ukończona

Acceptance Criteria — Given/When/Then

Format Gherkin: Given (kontekst), When (akcja), Then (oczekiwany wynik) — czytelny zarówno dla biznesu jak i developerów.

"Jako zarejestrowany użytkownik chcę zobaczyć historię zamówień"

AC1: Given: Użytkownik jest zalogowany, When: Klika 'Moje zamówienia', Then: Widzi listę max 50 ostatnich zamówień posortowanych od najnowszego

AC2: Given: Lista zamówień jest załadowana, When: Użytkownik kliknie na zamówienie, Then: Widzi szczegóły: produkty, kwotę, status, adres dostawy

AC3: Given: Użytkownik nie ma żadnych zamówień, When: Wchodzi w 'Moje zamówienia', Then: Widzi komunikat 'Brak zamówień' z linkiem do sklepu

Skala story points

Trywialnie prosta zmiana — zmiana tekstu, kolor przycisku

Prosta, dobrze znana zmiana — niewielkie ryzyko, jasne wymagania

Standardowe zadanie — kilka plików, znana technologia

Średniej złożoności — kilka komponentów, możliwe edge cases

Złożone — wiele komponentów, integracje, wyższe ryzyko

Bardzo złożone — rozważ podział na mniejsze stories

21+

Epic — zdecydowanie podziel, zbyt duże ryzyko w jednym sprincie

FAQ — user story

Co to jest user story?

User story (historyjka użytkownika) to krótki opis funkcji lub wymagania z perspektywy końcowego użytkownika, napisany w formacie: 'Jako [rola], chcę [cel/działanie], żeby [korzyść/wartość].' User stories są podstawowym elementem Product Backlogu w Agile i Scrum. Nie są specyfikacją techniczną — to zaproszenie do rozmowy o potrzebie użytkownika. Szczegóły są doprecyzowywane w kryteriach akceptacji i rozmowach w trakcie sprint refinement.

Czym są kryteria akceptacji (acceptance criteria)?

Kryteria akceptacji to lista warunków, które muszą być spełnione, by user story mogła być uznana za ukończoną. Odpowiadają na pytanie: 'Skąd wiemy, że ta funkcjonalność działa poprawnie?' Format Given/When/Then (Gherkin): 'Given [kontekst], When [akcja użytkownika], Then [oczekiwany wynik]'. Dobre AC są testowalne, jednoznaczne i pisane językiem biznesowym — nie technicznym. Zbyt mało AC = niejasne wymagania; zbyt dużo = micro-management.

Jaka jest różnica między user story a epicem?

Epic to duże wymaganie lub funkcjonalność — zbyt duża, by zmieścić się w jednym sprincie. Dzielona jest na mniejsze user stories. Hierarchia: Initiative (cel strategiczny) → Epic (duże wymaganie) → User Story (konkretna funkcjonalność w jednym sprincie) → Task (zadania techniczne do wykonania). Przykład: Epic 'System płatności' rozkłada się na stories: 'Jako klient chcę zapłacić kartą', 'Jako klient chcę zobaczyć potwierdzenie zamówienia', itd.

Co to jest DoD (Definition of Done)?

Definition of Done (DoD) to lista kryteriów które muszą być spełnione przez KAŻDĄ user story, by mogła być uznana za 'Done'. Typowa DoD: kod napisany i code reviewed, testy jednostkowe napisane i przechodzą, testy integracyjne przechodzą, dokumentacja zaktualizowana, feature flagiem wyłączone lub wypuszczone na produkcję, acceptance criteria spełnione, PO zaakceptował. DoD jest wspólnym kontraktem całego Scrum Teamu — eliminiuje nieporozumienia co to znaczy 'zrobione'.

Jak szacować user stories?

Najpopularniejsza metoda: Story Points (punkty storyowe) — relatywne, nie absolutne jednostki miary złożoności i ryzyka (nie czasu). Używaj Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 lub T-shirt sizes (XS, S, M, L, XL). Technika: Planning Poker — każdy szacuje indywidualnie, dyskusja gdy rozbieżności. Zasada: story powyżej 8-13 punktów to sygnał do podziału. Velocity (suma story points ukończonych w sprincie) pozwala prognozować tempo dostarczania.

Czytaj dalej