User Stories – Historyjki użytkownika

Pisząc o Scrum nie można zapomnieć o historyjkach użytkownika.
Co prawda  Scrum nie określa sposobu opisywania elementów rejestru produktu i pozwala na dodanie tam różnych artefaktów to historyjka użytkownika stałą się jednym z symboli metodyki Scrum.
User story, czyli historia użytkownika, opowiada o kliencie lub użytkowniku korzystającym z produktu. Zawiera imię, krótki opis oraz kryteria akceptacji czy warunki, które muszą być spełnione, by historia była kompletna. User story może być ogólne lub szczegółowe; ogólne historie zwane są epikami„[2].
Charakterystyczne dla historyjek użytkownika jest opisanie tego faktu w postaci:
„Jako <rola użytkownika> chcę…” – przykładowo: Jako Sprzedawca chcę dodawać do zamówienia klienta opcjonalne ubezpieczenie.
Rubin w swojej książce [1] definiuje kilka typów historyjek. Oto one:
  • historyjka użytkownika (ang. user story) — wygodny format służący do wyrażania pożądanej wartości biznesowej w różnorodnych elementach rejestru produktu. Historyjki użytkownika są konstruowane w taki sposób, aby mogły być zrozumiane w łatwy sposób zarówno przez ludzi ze strony biznesowej, jak i przez inżynierów. Mają prostą strukturę i zazwyczaj wyrażone są w formie zdania takiego jak „Jako <rola użytkownika> chcę osiągnąć <cel>, abym mógł otrzymać <korzyść>”. Są doskonałym miejscem do prowadzenia konwersacji. Mogą być pisane z różnym poziomem uszczegółowienia, a następnie stopniowo wzbogacane o detale.
  • historyjka zdolna do implementacji (ang. implementable story) — historyjka użytkownika o rozmiarze wystarczająco małym, aby zmieścić się swobodnie w sprincie. Równoznaczne z historyjką nadającą się do sprintu (ang. sprintable story).
  • historyjki techniczne (ang. technical stories) — historyjki „użytkownika” (należące do rejestru produktu), które nie dostarczają widocznej wartości dla użytkownika, ale w sposób istotny rozbudowują architekturę lub infrastrukturę potrzebną do dostarczenia takiej wartości w przyszłości.
  • historyjka z rejestru produktu (ang. product backlog item — PBI) — cecha produktu, błąd lub (sporadycznie) zadanie inżynieryjne mające wartość z punktu widzenia właściciela produktu. PBI to także element w rejestrze produktu.
Scrum pozwala, a raczej reaguje na konieczność dzielenie elementów w rejestrze produktu ze względu na ich stopień szczegółowości. W taki oto sposób powstały epiki, zwane w literaturze także eposami.
Historyjki, które są duże, nazywa epikami (ang. epics). Nie ma jakiegoś konkretnego algorytmu, który w sposób jednoznaczny pozwoliłby nam stwierdzić, czy dana historyjka jest już epikiem, czy nie. Zespoły często pytają, ile punktów powinna mieć historyjka, żeby można było powiedzieć, że nie jest epikiem. Zazwyczaj stosuję zasadę, że rozmiar historyjki nie powinien przekraczać połowy wartości prędkości zespołu, który będzie ją rozwijał. Jeżeli np. średnia prędkość zespołu wynosi 30 punktów, wielkość historyjki powinna oscylować wokół 15 punktów. Wszystko, co będzie większe, może być potraktowane jako epik„[4].
Inny sposób definiowania epik ma Rubin, który pisze [1]: „Epos to duża historia użytkownika o rozmiarze sięgającym nawet kilku miesięcy, która może wypełnić całą wersję dystrybucyjną lub nawet kilka z nich. Eposy są dobrym sposobem przechowywania wymagań o dużych rozmiarach. W odpowiednim czasie eposy są stopniowo przekształcane na zbiory małych historyjek użytkownika.
Dodatkowo Scrum pozwala na grupowanie historyjek. Taka agregacja historyjek nosi nazwę tematów (ang. themes). Temat to zbór historyjek powiązanych ze sobą wspólnym czynnikiem.  Ważne jest to, że każdy Zespół Scrumowy może zupełnie inaczej może określić wielkość epik i historyjek. Dla mnie zazwyczaj epika to proces biznesowy. Każdą aktywność procesu biznesowego opisuje od jednej do kilku historyjek użytkownika.
A jak Ty raisz sobie ze złożonością epik i historyjek?

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
[2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
[3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
[4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Podobne wpisy

  • Sprint Retrospective – Retrospekcja Sprintu Retrospekcja Sprintu (ang. Sprint Retrospective) jest głównym mechanizmem pozwalającym na uzyskanie informacji zwrotnej na temat kondycji procesu scrum. "Retrospekcja sprintu pozwala […]
  • Sprint Review – Przegląd Sprintu Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół prezentuje potencjalnie wykonalne przyrosty produktu. Na końcu każdego sprintu odbywa […]
  • Release Planning – Planowanie Wydania Planowanie wydania (ang. Release Planning) to czas, w którym na początku projektu zespół utworzy wysokiego poziomu plan realizacji produktu. Na początku projektu Zespół, z oczywistych […]
  • Sprint Planning Meeting – Planowanie Sprintu Na spotkaniu dot. Planowania Sprintu (ang. Sprint Planning Meeting) Zespół Scrum oraz Właściciel Produktu określają, które cechy i zadania będą poddane próbie wykonania w nadchodzącym […]
  • Estimating the Product Backlog – Szacowanie Rejestru Produktu Szacowanie rejestru produktu (ang. Estimating the Product Backlog) to moment, w którym okresowo Zespół Scrum będzie szacował wielkość każdej pozycji z rejestru produktu. Przed planowaniem […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry