Przewodnik po Scrumie | 19. Historie użytkowników – czym są?

Opublikowany: 2022-05-20

User Story to krótki opis nowej funkcjonalności Produktu lub jego ulepszenia. Nie zawiera rozwiązania technicznego, ale odpowiada na pytania dotyczące funkcjonalności: Kim jest użytkownik? Co robi Produkt? A jaki jest jego cel? User Story opisuje produkt w języku codziennym lub biznesowym, choć wskazuje również na zadania Zespołu Scrum, które mają na celu poprawę wydajności Zespołu.

Czym są historie użytkowników? – spis treści:

Wstęp
Historia użytkownika. Czyja to historia?
Jak korzystać z historii użytkownika?
Kryteria przyjęcia
Streszczenie

Wstęp

User Story to najczęstszy sposób formułowania zadań wykonywanych przez Zespół Scrumowy. Pojedyncza Historia Użytkownika definiuje niewielką funkcjonalność Produktu. Opisuje najmniejszy znaczący, częściowy cel produktu. Z tego powodu Historie użytkowników są bardzo krótkie.

Historie Użytkowników tworzone są przez cały czas pracy nad Produktem. Tworzone są w sposób ciągły, od momentu podjęcia decyzji o rozpoczęciu pracy, aż do realizacji Celu Produktowego.

Tworzenie historii użytkowników to zadanie Product Ownera. Na podstawie rozmowy z Klientem formułuje odpowiedzi na pytania pozwalające na stworzenie User Story i wpisuje je do Backlogu Produktu. Jednak historie użytkowników odzwierciedlają nie tylko potrzeby klientów.

Historia użytkownika. Czyja to historia?

Zespół Scrumowy tworzy User Story w celu zdefiniowania potrzeb Użytkownika, dlatego jest opisana językiem biznesowym. Innymi słowy wskazuje na korzyści, jakie jego wdrożenie przyniesie użytkownikowi produktu. Jednak w Backlogu Produktu mogą znajdować się również Historie Użytkowników, które opisują potrzeby Zespołu Deweloperskiego, na przykład usprawnienie przepływu pracy pomiędzy Developerami, lub opisujące potrzeby Właściciela Produktu, na przykład uporządkowanie Backlogu Produktu. W takich przypadkach Użytkownikiem w User Story jest Programista i Właściciel Produktu.

Możesz opisać User Story, odpowiadając na pytania 3W :

Kto?
Co robi?
Czemu?

Historia użytkownika jest wtedy zawarta w formule:

Jako [typ użytkownika] chcę [co robić?] Ponieważ [dlaczego? czemu?].

Przykładowe User Stories dotyczące funkcjonalności sklepu internetowego napisanych w tej formie ilustruje poniższa tabela:

Formuła ta pozwala nie tylko na sformułowanie User Story, ale także na stosunkowo łatwe przełożenie języka technicznego na biznes i odwrotnie . W rezultacie zarówno Deweloperzy, jak i Interesariusze wyraźnie widzą Cel i etapy jego postępu. Tworzenie dobrych User Stories metodą INVEST zajmiemy się również w osobnym artykule z serii Scrum Guide.

Jak korzystać z historii użytkownika?

Tworzenie schematycznego User Story to dopiero początek. Są sygnałami i punktami wyjścia do dyskusji o problemach i ich rozwiązaniach. Omawianie historii użytkowników odbywa się podczas planowania sprintu w celu ustalenia, jakie problemy techniczne zespół deweloperski doda do Backlogu sprintu.

Zazwyczaj w przestrzeni fizycznej Historie użytkowników są zapisywane na małych, kolorowych karteczkach przypiętych w miejscu pracy. Jednak w przestrzeni cyfrowej najlepiej sprawdzają się tablice cyfrowe udostępniane przez Zespół Scrumowy.

Zapisywanie historii użytkownika w ten sposób ma kilka zalet, ponieważ:

Podkreśla autonomię każdego User Story – każda ma osobny framework i może być wykonywana niezależnie od pozostałych
Podkreśla dynamikę User Stories – kolejność ich realizacji jest renegocjowana przez Zespół Scrumowy, a aktualna kolejność realizacji jest widoczna na tablicy dzięki fizycznemu ułożeniu kart z User Stories
Służy jako przypomnienie – dzięki wizualnej reprezentacji User Stories, Zespół Scrumowy ma w zasięgu wzrok drogowskaz, który przypomina o celu przy tworzeniu szczegółowych rozwiązań.

Zespół Deweloperski szacuje nakład pracy potrzebny do ukończenia Historyjki Użytkownika za pomocą dni, roboczogodzin lub Punktów Historii.

Kryteria przyjęcia

Historyjka Użytkownika musi mieć określone kryteria akceptacji w momencie, gdy zostanie zaakceptowana do opracowania przez Zespół Deweloperski. Kryteria akceptacji określają, w którym momencie prace nad User Story można uznać za zakończone.

W ten sposób zarówno klient, jak i programiści wiedzą, jak ich praca przełoży się na wartość biznesową. Zazwyczaj Historię Użytkownika uważa się za zakończoną, gdy określony w niej użytkownik może wykonać opisaną akcję. Korzystając z powyższego przykładu, spójrz na tę historię użytkownika z treścią:

Klient może kupić magiczną różdżkę jednym kliknięciem.

Kończy się, gdy na stronie sklepu internetowego pojawi się działający przycisk „Kup Teraz” , który korzysta z domyślnych informacji o płatnościach i wysyłce dla zalogowanego użytkownika.

Streszczenie

Historia użytkownika to zwięzły opis nowej funkcjonalności lub ulepszenia Produktu. Służy jako najmniejszy Cel wyrażony językiem biznesowym, czyli z perspektywy wartości biznesowej i użytkownika. Pomaga jasno określić zadanie do wykonania oraz kryteria jego realizacji.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Autor: Caroline Becker
Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.
Zobacz wszystkie posty

Przewodnik po Scrumie:

Słowniczek podstawowych pojęć, ról i pojęć
Co to jest Scrum?
Wartości Scrum
Jak wdrożyć Scrum w swojej firmie?
Zespół Scrumowy - co to jest i jak działa?
Kim jest Product Owner?
Najczęstsze błędy Product Ownera
Kim jest Scrum Master?
Charakterystyka dobrego Scrum Mastera
Najczęstsze błędy Scrum Mastera
Jakie statystyki i metryki powinien śledzić Scrum Master?
Współpraca Product Ownera ze Scrum Masterem
Zespół Deweloperski w Scrum
Najczęstsze błędy programistów
Artefakty Scrum
Skalowanie Scrum
Backlog Sprintu
Czym jest Backlog Produktu?
Czym są historie użytkowników?
Tworzenie najlepszej historii użytkownika z INVEST
Najczęstsze błędy User Story
Kryteria akceptacji historii użytkownika
Szacowanie i punkty fabularne w Scrumie
Poker Planowania
Drużynowa gra szacowania
Definiowanie przyrostu
Wydarzenia scrumowe
Czym jest Sprint w Scrumie?
Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
Co to jest wykres spalania?
Jak stworzyć i zinterpretować wykres spalania?
Zalety i wady wykresu spalania
Tablice Kanban w Scrum i Scrumban
Velocity in Scrum - Szybkość Zespołu Deweloperskiego
Codzienny Scrum
Planowanie sprintu
Przegląd sprintu
Czym jest retrospektywa sprintu?
Typowe błędy podczas Retrospektywy Sprintu
Pielęgnacja Backlogu Produktu