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

Dobry przykład:

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

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

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

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

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.