User Story – przykład i zastosowanie

Czy User Story to wygodna i wystarczająca forma opisu wymagań w projektach informatycznych? Czy sprawdzi się wszędzie, zaczynając od start-upów, a kończąc na dojrzałych korporacjach?
Ja mam swoje zdanie bazujące na wieloletniej pracy z User Story. Definicję, przykładowe User Story i ich zastosowanie, oraz moją opinię znajdziesz poniżej.

W kolejnych rozdziałach przeczytasz o:

Klasyczna definicja User Story, czyli CCC

Historia User Story sięga końca lat 90-tych ubiegłego wieku, kiedy to Kent Beck opublikował zestaw praktyk związanych z wytwarzaniem oprogramowania pod nazwą Extreme Programming (XP). Według tego modelu User Story powinno być:

  • zdefiniowane przy użyciu języka naturalnego,
  • opracowane z perspektywy konkretnego użytkownika,
  • nastawione na dostarczenie wartości dla tego użytkownika – efektu,
  • możliwe do dostarczenia w krótkim, skończonym czasie.

Rok wcześniej (1998) Alistair Cockburn określił User Story jako “zaproszenie do rozmowy”, co dobrze wpasowuje się w powszechną obecnie koncepcję CCC (Card, Conversation, Confirmation) wprowadzoną w 2001 roku przez Rona Jeffriesa.

Według tej koncepcji User Story składa się z trzech elementów:

1. User Story Card

Karta (Card), czyli nagłówek/tytuł User Story.

Wraz z początkami User Story przyjęto za standard opis według konwencji:

Jako <użytkownik> chciałbym <możliwość, czynność>, aby <korzyść>

Czy warto opisywać User Story w ten sposób? Przykłady podam w dalszej części.

2. User Story Conversation

Powyższy tytuł to nie wszystko. W trakcie prac nad User Story konieczne jest doprecyzowanie detali (Conversation). W klasycznej definicji odbywa się to w trakcie rozmowy, z której wnioski lądują właśnie w User Story. 

Ważne jest to, aby te wnioski faktycznie znalazły się w opisie historyjki, a nie pozostały jedynie w głowach uczestników.

3. User Story Confirmation

I trzecie C, czyli dyskusje nad wymaganiami powinny zakończyć się ustaleniem kryteriów akceptacji danej historyjki. Jest to test, lub zestaw testów, których wykonanie potwierdzi, że historyjka została dostarczona i pozwala osiągnąć założone korzyści.

Tak jak w przypadku Conversation, tak i tutaj ważne jest zapisanie tych testów, a nie tylko omówienie.

Czy zawsze stosować Jako…chciałbym…aby?

Przedstawiona klasyczna struktura zapisu User Story dobrze systematyzuje opis historyjek. Ma jednak pewne wady, czyli:

  • utrudnia opisywanie wymagań technicznych. Takie zadania lepiej opisywać w tradycyjnej, analitycznej formie, nie korzystając ze schematu “jako…chciałbym…aby…”
  • komplikuje przeglądanie backloga, gdy np. 100 historyjek zaczyna się od: “jako klient firmy ABC chciałbym, aby…” – wiele systemów do zarządzania historyjkami nie wyświetli całego tekstu, więc User Story będą nie do rozróżnienia. Proponuję upraszczać tytuły, a klasyczny opis wynikający z CCC wpisać w treści historyjki.

User Story – przykłady

Zgodnie z powyższym schematem, zdefiniowanie przykładowego User Story może przebiegać następująco.

User Story – przykład dla e-commerce

Card

Jako klient sklepu meblowego chciałbym odfiltrować tylko te zestawy mebli, które mieszczą się do mojego pokoju, dzięki czemu przeglądanie ofert zajmie mi dużo mniej czasu. 

Conversation

Przykładowy zapis z rozmowy zespołu:

Wprowadzam rozmiary pokoju i system od razu “wie”, które zestawy na pewno są nieodpowiednie (dokładny algorytm obliczeń – patrz diagram na stronie …)

Pomocny byłby edytor wizualny, w którym można nanieść nie tylko drzwi czy okna, ale też inne posiadane obecnie meble, które klient chce zachować w pokoju. 

Niektóre ściany mają też ograniczenia, np. klient nie chce zasłonić ładnej tapety, albo nie może nic powiesić na zaimprowizowanej ścianie z kartongipsu. 

Z czasem mogą pojawić się dodatkowe ograniczenia.

Klient na końcu dostanie listę tych zestawów, które spełniają oczekiwania. Lista będzie posortowana według kryteriów stosowanych standardowo w sklepie, czyli np. ceny, opinii, dostępności itp.

Confirmation

  • Gdy wprowadzę rozmiary pustego pokoju, to system wyliczy czy konkretny zestaw mebli mieści się w nim czy nie.
  • Gdy wskażę w planie pokoju okna i drzwi, to system wyliczy czy konkretny zestaw mebli może się w nim zmieścić w taki sposób, aby umożliwić otwarcie okien i drzwi. 
  • Gdy naniosę dodatkowe meble na plan pokoju, to system uwzględni je w obliczeniach i zasugeruje tylko te zestawy, dla których możliwe będzie ułożenie starych i nowych mebli razem.
  • Gdy naniosę informacje o dodatkowych ograniczeniach na ścianach, to system potraktuje je tak samo jak okna czy drzwi i nie zasugeruje ustawienia tam mebli. 
  • Gdy moje wymagania spełni kilka zestawów mebli, to będę mógł posortować ją według różnych kryteriów, np. ceny, opinii, dostępności, materiału, koloru. 

Jak stosować i nie stosować User Story – przykłady

Przykładowe User Story to tylko krok na drodze do przygotowania wartościowego backloga. Jest jeszcze kilka innych elementów niezbędnych do zastosowania.

Odpowiednio dobrany użytkownik (persona) 

W pierwszej części User Story występuje osoba – użytkownik, czyli “Jako ktoś, chciałbym…”

Jak zdefiniować tego kogoś?

  • Użytkownik w User Story powinien reprezentować szeroką grupę odbiorców systemu. To nie może być ekstremalny charakter. W przykładzie meblarskim to nie mógłby być klient, który kupuje drogie, mahoniowe meble, jeżeli sklep specjalizuje się w ofercie ekonomicznej, dostosowanej do przeciętnego odbiorcy.
  • Profil i zachowanie użytkownika powinno wynikać z badań i obserwacji. To nie może być gdybanie typu “ktoś tak pewnie robi”, “wyobraź sobie, że jesteś … i robisz …”. Szkoda czasu na takie wymyślanie użytkowników. Wartościowe persony są definiowane na przykład:
    • na podstawie ankiet i rozmów z użytkownikami,
    • w trakcie rozmów z osobami, które mają z nimi bezpośredni kontakt (np. sprzedawcy),
    • w wyniku obserwacji ich interakcji z systemem,
    • na podstawie ogólnodostępnych badań statystycznych.

W przeciwnym razie już na starcie pojawi się spore ryzyko, że User Story może dostarczyć coś, czego nikt nie chce. 

Uzasadnienie, czyli konkretna korzyść z każdego User Story

Każda historyjka przekłada się z czasem na koszt poniesiony na jej wytworzenie i utrzymanie. W zamian za ten koszt musi powstać mierzalna wartość – od razu lub za dopiero jakiś czas. W przeciwnym razie będzie to strata z perspektywy biznesowej.

Pracując nad User Story zastanów się więc:

  • jaka jest skala problemu, który chcesz rozwiązać – wyraź to w liczbach,
  • jaki będzie efekt po zrealizowaniu tego User Story – na ile zmienią się te wskaźniki?
  • czy zysk będzie adekwatny do kosztów?

Wyliczanie wartości User Story – przykład

Przykład User Story dla e-commerce. Wspomniany już sklep meblowy:

  • Przeprowadzono ankietę – zebrano informacje od klientów, którzy ostatecznie nie zdecydowali się na zakupy w tym sklepie. 
  • Tylko 5% ankietowanych podkreśliło, że nie byli w stanie sprawdzić, czy meble zmieszczą się w ich mieszkaniu. Dużo częstszą przyczyną była słaba wizualizacja kolorów, brak opisu materiału, niejasne informacje na temat opcji zakupu i jeszcze kilka innych powodów.
  • Przeliczając to na potencjalny zysk nieuzasadnione jest rozpoczynanie prac nad tym wymaganiem. Środki potrzebne na zbudowanie tak złożonych algorytmów będą niewspółmiernie większe od potencjalnych zysków.
  • Warto skupić się na innych problemach, które przy niższych nakładach szybciej przełożą się na wyniki biznesowe. 

Analiza z perspektywy procesu

Każde User Story to osobna historyjka. Systemy to jednak nie pozszywane ze sobą losowo części, ale funkcjonalności ułożone w moduły i procesy. Dlatego odkładanie wszystkich pomysłów na stos zwany backlogiem nie jest najlepszym pomysłem.
Z takiej sterty historyjek ciężko zbudować coś spójnego. Efektem może być nieoptymalny produkt. Na przykład samochód wyścigowy, w którym założono dynamiczną skrzynię biegów, a do tego wstawiono zbyt słaby silnik, który i tak nie wykorzysta jej potencjału.

Każde z wymagań być może nawet zostało spełnione. Tylko, że osobno. 

Dlatego User Story powinny być zawsze analizowane z perspektywy procesu, a każda historyjka musi mieć swoje miejsce w sekwencji prowadzącej do uzyskania oczekiwanej wartości. Jeżeli jest coś poza procesem, to jest to prawdopodobnie zbędne.
Poniżej załączam przykład z narzędzia Visual Pardigm, które pozwala na mapowania User Story do kroków procesu zapisanych w notacji BPMN. 

diagram procesu i user story - przykład

(źródło: https://www.visual-paradigm.com/features/agile-user-story-mapping-tool/)

User Story Map jako uniwersalne rozwiązanie

Innym sposobem przedstawienia historyjek użytkowników jest Mapa Historyjek Użytkowników (User Story Map) – czyli wizualizacja procesu, z perspektywy uczestników.

Aby zbudować mapę historyjek użytkownika nie potrzebujesz wiedzy na temat BPMN czy innej notacji. W zamian potrzebne są umiejętności z zakresu prowadzenia efektywnych warsztatów, moderacji, zarządzania dynamiką grupy czy motywacji. To wszystko uzupełnione umiejętnościami zadawania odpowiednich pytań, ogólną dociekliwością i analitycznym podejściem.

User Story Map przygotujesz choćby w arkuszu kalkulacyjnym. Tak właśnie powstała poniższa mapa.

user story mapa - przykład

Budowanie całego backloga historyjek

User Story są pisane językiem naturalnym. Może więc kusić przekazanie opieki nad backlogiem osobom znającym biznes, bez specjalnego przygotowania do tej roli.
Zdecydowanie nie polecam takiego rozwiązania. Backlog będzie wtedy chaotyczną listą ogólnych życzeń i pomysłów.
Zaimplementowanie systemu na tej podstawie będzie niemożliwe. 

Aby więc przygotować spójny i wartościow zestaw User Stories, pokrywających kluczowe procesy, konieczne jest metodyczne podejście, takie jak mapowanie story do BPMN czy tworzenie User Story Map. 

Do tego warto dodać:

  • spójny słowniki pojęć, 
  • zapisywanie oczekiwań w postaci liczbowej, 
  • precyzyjne określanie testów akceptacyjnych 
  • i wiele więcej…

To z kolei wymaga odpowiedniego przygotowania i kompetencji ze strony osób opracowujących te wymagania. 

Co dalej?

Zdefiniowanie backloga pełnego dobrych historyjek to do dopiero początek procesu.

Następnie należy, na przykład:

  • podzielić go na kolejne wersje, mając na uwadze cele biznesowe,
  • uszczegółowić wymagania i potwierdzić ich wykonalność,
  • ustalić sposób realizacji od strony technicznej,
  • oszacować czasochłonność prac.

Chcesz jeszcze bardziej zgłębić temat? Poznaj technikę User Story Mapping!

Witaj w Project Makers!

Cześć, jestem Artur.

Uruchomiłem bloga Project Makers po to, żeby pokazywać jak przy pomocy podstawowych narzędzi i zdrowego rozsądku, każdy może w krótkim czasie osiągnąć mistrzostwo w zwinnym zarządzaniu projektami.

A wszystko zaczęło się od niezaliczonych egzaminów z programowania
(czytaj dalej…)

Partnerzy Project Makers

Masz 10 minut?
Zrób test zwinności projektu!

Szukasz ciekawych, treści?

Najnowsze wpisy

  • All Post
  • Definiowanie wymagań
  • Narzędzia
  • Planowanie
  • Praca z celami
  • Rekomendacje
  • Rozmowy z ekspertami
  • Zarządzanie budżetem
  • Zarządzanie jakością
  • Zarządzanie zespołem

Znajdź na blogu

Szukasz ciekawych, treści
o Zwinnym Zarządzaniu Projektami?

Zapisz się do Newslettera Project Makers!
Najnowsze trendy, ciekawostki, narzędzia.
Tylko sprawdzone treści. 

Współpracuję z:

Project Makers
u. Dworcowa 8
44-240 Żory
artur@projectmakers.pl

Copyright © 2024 Project Makers