User story to krótka obietnica rozmowy o potrzebie użytkownika. Przypadek użycia to uporządkowany opis interakcji aktora z systemem prowadzącej do celu, wraz z wariantami i błędami. Oba formaty mogą opisywać ten sam obszar, ale odpowiadają na inną potrzebę dokumentacyjną.
Nie ma zasady, że projekt zwinny wymaga wyłącznie user stories, a formalny — przypadków użycia. Wybór zależy od złożoności interakcji, liczby wyjątków, ryzyka oraz tego, jaką wiedzę trzeba utrwalić poza rozmową.
Porównanie formatów
| Wymiar | User story | Przypadek użycia |
|---|---|---|
| Punkt ciężkości | Rola, potrzeba i wartość | Przebieg osiągnięcia celu |
| Objętość | Jedno zdanie plus kryteria i rozmowa | Aktorzy, warunki, kroki, warianty, rezultat |
| Najlepsze użycie | Planowanie i iteracyjne doprecyzowanie zakresu | Złożona interakcja lub wiele ścieżek błędów |
| Ryzyko | Hasło uznane błędnie za pełną specyfikację | Zbyt wczesne rozpisanie detali i trudna aktualizacja |
| Jednostka | Wartość możliwa do dostarczenia | Cel aktora wobec systemu |
Przykład porównawczy: anulowanie zamówienia
Ten sam temat jako user story
Jako klient sklepu chcę anulować zamówienie przed rozpoczęciem wysyłki, aby uniknąć odbioru i późniejszego zwrotu.
To zdanie daje perspektywę i wartość, ale nie odpowiada na pytania o częściową wysyłkę, płatność, kupon, zamówienie gościnne czy równoczesną zmianę statusu w magazynie. Informacje należy uzgodnić podczas rozmowy i utrwalić w kryteriach akceptacji, regułach albo modelu procesu.
- Mając opłacone zamówienie w statusie „przyjęte”, gdy klient anuluje całość, system zmienia status na „anulowane” i tworzy zwrot pełnej zapłaconej kwoty.
- Mając zamówienie w statusie „pakowanie”, system nie udostępnia anulowania i wyjaśnia możliwość zwrotu po dostawie.
- Jeśli status zmieni się na „pakowanie” między otwarciem ekranu a potwierdzeniem, system nie anuluje zamówienia i pokazuje aktualny stan.
Ten sam temat jako przypadek użycia
UC-07: Anulowanie zamówienia. Aktor główny: klient. Cel: zatrzymać realizację zamówienia i odzyskać należność. Warunki początkowe: klient ma dostęp do zamówienia; żadna pozycja nie została przekazana do wysyłki. Wyzwalacz: klient wybiera „Anuluj zamówienie”. Rezultat sukcesu: zamówienie jest anulowane, dyspozycja zwrotu utworzona, klient otrzymuje potwierdzenie.
Przebieg podstawowy: 1. System pokazuje pozycje i kwotę zwrotu. 2. Klient potwierdza anulowanie. 3. System ponownie sprawdza status magazynowy. 4. System anuluje pozycje. 5. System tworzy dyspozycję zwrotu zgodnie z metodą płatności. 6. System pokazuje termin zwrotu i wysyła potwierdzenie.
Wariant 3a: pozycja trafiła do pakowania — system nie zmienia zamówienia i informuje o zwrocie po dostawie. Wariant 5a: operator płatności jest niedostępny — zamówienie pozostaje anulowane, dyspozycja otrzymuje status „do ponowienia”, a klient widzi przewidywany termin.
Przypadek użycia pokazuje kolejność, odpowiedzialność systemu i stan po błędzie. Nadal może wymagać osobnych tabel reguł płatności i wymagań wydajnościowych. Nie powinien zawierać każdego kliknięcia ani projektu ekranów, jeśli nie ma to znaczenia dla zachowania.
Kiedy wybrać user story
- Zespół i interesariusze regularnie rozmawiają o zakresie.
- Zmiana może być dostarczona jako mała, wartościowa część.
- Interakcja jest prosta, a wyjątki mieszczą się w kilku kryteriach.
- Ważne jest elastyczne planowanie i priorytetyzacja.
- Szczegóły są utrzymywane w powiązanych regułach, projektach lub testach.
Kiedy przypadek użycia daje więcej wartości
- Cel wymaga wielu kroków i współpracy z innymi systemami.
- Alternatywne ścieżki istotnie zmieniają stan lub odpowiedzialność.
- Trzeba zachować wspólny obraz end-to-end ponad kilkoma elementami backlogu.
- Proces jest regulowany, krytyczny lub realizowany przez wielu dostawców.
- Użytkownicy i zespół rzadko mają możliwość bezpośredniego doprecyzowania.
Jak łączyć formaty bez kopiowania
Przypadek użycia może opisywać stabilną całość, a user stories — kolejne przyrosty realizacji. Story „anulowanie całego zamówienia”, „anulowanie wybranej pozycji” i „ponowienie zwrotu” wskazują UC-07 oraz konkretne warianty. Reguła statusów pozostaje w jednym miejscu. Zmiana reguły nie wymaga poprawiania jej kopii w trzech historiach.
Nie zamieniaj każdego kroku przypadku użycia w osobną user story. Krok techniczny rzadko dostarcza samodzielną wartość. Podział powinien uwzględniać użyteczny rezultat i bezpieczny stan danych.
Jak utrzymywać opis, gdy proces się zmienia
Przypadek użycia powinien mieć właściciela i status, a historie odwoływać się do jego identyfikatora. Gdy zmienia się reguła anulowania, najpierw aktualizujemy źródło reguły i przypadek użycia, następnie wykonujemy analizę wpływu na aktywne stories oraz testy. Nie poprawiamy tylko elementu znajdującego się akurat w sprincie.
Po wdrożeniu historia może zostać zamknięta, lecz przypadek użycia nadal opisuje zdolność systemu. Jeśli służy utrzymaniu lub kolejnym zmianom, powinien odzwierciedlać obowiązujący przebieg. Jeżeli nie ma takiej potrzeby, można zachować go jako wersjonowany artefakt projektu zamiast udawać żywą dokumentację.
W obu formatach unikaj kopiowania definicji statusów, wzorów obliczeń i polityk bezpieczeństwa. Powiązanie z katalogiem reguł lub słownikiem jest czytelniejsze oraz ogranicza liczbę miejsc aktualizacji.
Checklista wyboru formatu
- Wiadomo, kto będzie czytał i aktualizował opis.
- Format odpowiada złożoności interakcji i ryzyku.
- User story nie jest traktowana jako pełna specyfikacja bez rozmowy.
- Przypadek użycia opisuje zachowanie, nie układ interfejsu.
- Reguły i dane mają jedno źródło zamiast kopii.
- Wyjątki kończą się jednoznacznym stanem.
- Elementy backlogu pozostają powiązane z celem aktora.
- Kryteria akceptacji pozwalają odebrać dostarczany przyrost.
Oba formaty można uzupełnić modelem procesu, stanów lub danych. Jeżeli sednem problemu jest kolejność odpowiedzialności między działami, sam przypadek użycia systemu nie pokaże całego obrazu. Jeżeli ryzyko leży w kombinacji reguł, tabela decyzyjna będzie czytelniejsza niż mnożenie wariantów tekstowych.
Niezależnie od formatu zastosuj zasady z poradnika jak napisać dobre wymaganie. Scenariusze do user story możesz przygotować według materiału jak opisać kryteria akceptacji.
