Tworzenie historyjek użytkownika to pomysł twórców Extreme Programming (EX) czyli Kenta Becka i Martina Fowlera, który został później przejęty przez Scrum’a jako jeden z artefaktów.

Historyjki użytkownika realizują manifest Agile a w szczególności dwa jego elementy:

Działające oprogramowanie ponad obszerną dokumentację.

Współpracę z klientem ponad formalne ustalenia.

Przykładowy szablon historyki:

JAKO <TYP UŻYTKOWNIKA> CHCĘ WYKONAĆ <NAZWA ZADANIA> ŻEBY OSIĄGNĄĆ <CEL>.

Inny możliwy szablon to:

JAKO <ROLA UŻYTKOWNIKA> CHCIAŁBYM <AKCJA/FUNKCJONALNOŚĆ> ABY <CEL>.

Pamiętaj, że od tego, jak zapiszecie historyjkę klienta, dużo ważniejsza jest rozmowa, o której papierowy kartonik ma nam przypominać. Historyjki użytkownika muszą opisywać funkcjonalność, która ma określoną wartość dla użytkownika.

Ron Jeffries w XP Magazine zdefiniował zasadę „Trzy k„

1. K – karta: historyjka jest zapisana na małym kawałku papieru.
2. K – konwersacja: mała kartka papieru, z krótkim tekstem jest katalizatorem rozmowy na jej temat.
3. K – konfirmacja: czyli testy akceptacyjne najczęściej zapisywane są na odwrocie papierowych kartoników.

Definition of Done „DoD„

Każda historyjka powinna mieć jasno sprecyzowane warunki, których spełnienie będzie oznaczało wykonanie zadania w całości.

Poprawnie zdefiniowane historyjki są zgodne z cechami opisanymi za pomocą akronimu INVEST

Istniejące samodzielnie (ang. Independent)

Historyjki są niezależne, gdy możemy je implementować w dowolnej kolejności. Niesie to za sobą dwie korzyści. Właściciel produktu może dowolnie ustalać priorytet względem innych historyjek oraz ocena historyjki nie jest zależna od stopnia wykonania innej historyjki.

Negocjowalne (ang. Negotiable)

Historyjki nie są specyfikacją wymagań. Zawierają jedynie krótki opis funkcjonalności zapisany na małej kartce papieru. Na więcej nie ma miejsca. Reszta czyli wszystkie szczegóły i drobnostki dopracowuje się w rozmowie.

Wartościowe (ang. Valueable)

Historyjka użytkownika jest funkcjonalnością, której implementacja przenika przez wszystkie warstwy systemu. Przykładowo, treścią historyjki użytkownika nie może być projekt bazy danych. Wykonanie warstwy bazodanowej jest dla użytkownika kompletnie obojętne. Użytkownik systemu wymaga pojedynczej funkcjonalności, która realizuje dany scenariusz. Sama baza danych jest bezużyteczna. Przykładem wartościowej historyjki użytkownika jest zaimplementowanie możliwości logowania się do systemu. Aby taka funkcjonalność była udostępniona użytkownikowi wymagane jest zaimplementowanie kawałka bazy danych, dostępu do tych danych, logiki oraz interfejsu użytkownika.

Estymowalne (ang. Estimable)

Historyjka musi być do tego stopnia czytelna, żeby na jej podstawie, Właściciel produktu mógł ją umiejscowić względem pozostałych oraz zaplanować pracę.

Trzy czynniki czyniące historyjkę estymowalną to:

• Konwersacja – Treść historyjek pisana jest wspólnie całym zespołem wraz właścicielem produktu. Właściciel Produktu odpowiada za przygotowanie historyjek, nadanie im priorytetów oraz utrzymanie porządku.
• Rozmiar – Historyjki muszą być niewiększe niż możliwe do zaimplementowania w jednej iteracji.
• Zespół – Łatwość szacowania historyjek użytkownika zależy również od doświadczenia i wiedzy zespołu, który nad nim pracuje.

Są małe (ang. Small)

Historyjki są małe wtedy, gdy jest możliwe wykonać je w jednej iteracji. Historyjki, które będziemy implementować w pierwszej kolejności powinniśmy rozbijać na mniejsze, przechodząc od ogółu do szczegółu.

Natomiast funkcjonalności, które będziemy implementować kiedyś w przyszłości powinny być ogólnym zapisem idei. One mogą być większe. Nie ma sensu poświęcać energię na coś co ma się stać w dalekiej przyszłości. Może się okazać, że wyniku przebiegu zdarzeń w projekcie ta dana historyjka nigdy nie wejdzie w skład iteracji.

Testowalne (ang. Testable)

Testy akceptacyjne są bardzo ważnym elementem każdej historyjki. Są jej nieodzownym elementem. Nie ma historyjki jeśli nie ma testu akceptacyjnego. Nie ma mowy o tym, że napisaliśmy dobrą historyjkę, gdy nie jesteśmy wstanie jej przetestować.

Przykład błędnej i poprawnej historyjki użytkownika

Mike Cohn w książce „User Stories Applied”  podał przykład błędnej, nietestowalnej historyjki oraz jej poprawną wersję.

Błędna wersja:

UŻYTKOWNIK NIGDY NIE POWINIEN DŁUGO CZEKAĆ NA WYŚWIETLENIE SIĘ DOWOLNEGO EKRANU.

Poprawna wersja:

CZAS WYŚWIETLANIA SIĘ NOWEGO EKRANU WYNOSI 2 SEKUNDY W 95% PRZYPADKÓW.

Bibliografia:
„SCRUM O zwinnym zarządzaniu projektami” Mariusz Chrapko
„User Stories Applied” Mike Cohn