Czym jest Scrum czytelnicy Journala doskonale wiedzą. Podejmowaliśmy ten temat między innymi w artykułach: “Co to jest Scrum?” “Retrospektywa Scrum”, “5 wartości Scrum”.
Czas zatem omówić rolę, jaką pełni we frameworku Scrum User Story, czyli Historyjka Użytkownika.
A pełni rolę niebagatelną.
Metodyki zwinne są sfokusowane na potrzebach użytkownika końcowego, którego oczekiwania, doświadczenia, kompetencje, możliwości, przyzwyczajenia powinny być w szczególności uwzględniane w procesie projektowania, wdrażania, rozwijania i udoskonalania produktu cyfrowego.
Poznanie, zrozumienie tych wymagań stanowi clue podejścia zwinnego.
Spełnić te potrzeby, oczekiwania, to do pewnego stopnia zagwarantować użytkownikowi pożądane doświadczenia w czasie korzystania z produktu cyfrowego.
User Story jest narzędziem, pozwalającym spojrzeć na stronę internetową, aplikację mobilną z perspektywy jej przyszłego użytkownika.
Dobrze napisane User Stories pozwalają zaoferować przyszłym użytkownikom, klientom pożądaną wartość dodaną.
Nie będzie wielką przesadą powiedzenie, że jeśli nie byłoby User Stories to niezwłocznie należałoby je wymyślić i zacząć stosować, bowiem w Agile są one kluczowym narzędziem, służącym do opisu danej funkcjonalności z perspektywy jej modelowego użytkownika.
Czym są zatem User Stories i w jaki sposób można je zdefiniować? Jaką pełnią rolę we frameworku Scrum lub szerzej w procesie tworzenia oprogramowania, produktów cyfrowych?
Czy User Stories są konieczne? Jakie korzyści niesie wykorzystywanie User Stories? W jaki sposób powinno się pisać User Story?
Oto, nasze podstawowe pytania, na które odpowiedzi będziemy udzielać w tym artykule.
Serdecznie zapraszamy do lektury!
Szukasz software house?
User Story Scrum, czyli czym są Historyjki Użytkownika?
Historyjki użytkownika kojarzyć należy z metodykami zwinnymi, w szczególności z metodologią Agile i jej najbardziej popularnym frameworkiem Scrum.
User Story, Historyjka Użytkownika przede wszystkim pozwala określić, czego użytkownik chce oraz dlaczego tego chce.
User Story jest formą wyrażenia wymagania funkcjonalnego w sposób możliwie lapidarny, komunikatywny, prosty i co najważniejsze, czego absolutnie nie można pominąć, wyrażony z perspektywy użytkownika.
Historyjki Użytkownika zamiast operować opisem, zbiorem cech, czy określeń odnośnie danej funkcjonalności, odwołują się do prostego wyrażenia celu, potrzeby oraz czasami sposobu ich osiągnięcia i zaspokojenia.
Mówiąc skrótowo - Historyjki Użytkownika się opowiada, a nie o nich opowiada. Różnica wydawać się może zbyt subtelna i czysto lingwistyczna, ale w praktyce oznacza to zupełnie coś innego.
Opowiedziana Historyjka Użytkownika o wiele łatwiej przekazuje oczekiwania i jest o wiele łatwiejsza do zrozumienia przez zróżnicowanych interesariuszy.
User Story bywają użyteczne nie tylko dla zespołów projektowych, developerskich, ale także dla pozostałych osób zaangażowanych w projekt.
Sam termin User Story nie jest nowy. Został stworzony w 1997 roku, a szerszy rozgłos nabrał wraz z publikacją książki autora tego pojęcia Kenta Becka pt. “Extreme Programming Explained” w 1999 roku.
Zgodnie z pierwotnym sensem, znaczeniem tego terminu, User Story to atrybuty produktu, opisane z punktu widzenia użytkownika, klienta.
Wyjątkowość User Stories polega na szczególnej perspektywie przekazania oczekiwań. Chodzi nie o to, co system powinien oferować, co powinien posiadać, ale co może dla użytkownika zrobić.
Cały ciężar jest przeniesiony z produktu na jego użytkownika.
Odwołajmy się do obrazowego przykładu. Radio nie jest użyteczne, dlatego, że pozwala odbierać fale radiowe, ale dlatego, że pozwala użytkownikowi wysłuchać ulubioną audycję radiową.
Radio, które pozwala “złapać daną stację”, w której jest emitowana audycja, oferuje zatem pewną wartość, której słuchacz oczekuje.
Radio, które nie “łapie” pożądanej częstotliwości, gwarantującej dostęp do audycji, będzie postrzegane jako urządzenie nic nie wnoszące do codziennego życia słuchacza.
Nie inaczej jest z funkcjonalnościami oferowanymi na stronach internetowych, czy w aplikacjach webowych.
Samo ich oferowanie nie wnosi wartości. Wartość pojawia się wraz z wpisaniem się w potrzeby, oczekiwania, doświadczenia, przyzwyczajenia, możliwości danej grupy użytkowników.
A Agile ów cel pomagają urzeczywistnić właśnie User Stories.
W metodyce Agile, we frameworku Scrum, User Story to po prostu krótki - jedno-, dwuzdaniowy - nieformalny, prosty opis tego, co użytkownik końcowy chce zrobić, osiągnąć za pomocą oprogramowania.
Jest to opis celu, jaki chce uzyskać, wartości, jaka jest dla niego ważna i cenna, korzyści, jakie zamierza odnieść.
Historyjki Użytkowników pozwalają określić, jakie cechy, funkcje powinien posiadać produkt. User Stories stanowią bardzo ważne narzędzie definiowania potrzeb użytkowników.
Mówiąc o tym, czego użytkownicy, by sobie życzyli, mówią o swoich potrzebach, jednocześnie mówią o swoich oczekiwaniach względem produktu cyfrowego.
Formułują swoje wyobrażenia względem sposobu działania, celów, jakie chcą osiągać. W sposób możliwie obrazowy, konkretny.
Tworzony na podstawie User Story kod przyszłej aplikacji webowej lub mobilnej powinien stanowić, w sensie funkcjonalnym oraz w sensie użyteczności, odpowiedź na te potrzeby, oczekiwania, cele.
Historyjki Użytkownika pozwalają jednocześnie nadać tym potrzebom formę, która jest uniwersalnie zrozumiała - a przynajmniej taką należy ją czynić - oraz łatwa, szybka do przekazania.
W Scrumie User Story, Historyjka Użytkownika reprezentuje także najmniejszą jednostkę pracy, jaką w ramach danego projektu należy wykonać.
Podkreślmy to jeszcze raz, User Story w nieformalny sposób opisuje funkcję oprogramowania, aplikacji webowej lub mobilnej w języku naturalnym, używanym przez użytkownika końcowego.
Użycie języka naturalnego, zamiast na przykład żargonu informatycznego, ma także tę zaletę, że pozwala Historyjkom Użytkownika nadać formę, która będzie zrozumiała dla członków zespołu scrumowego, pozostałych interesariuszy oraz klientów software house`u, czy agencji UX.
User Stories najczęściej są grupowane w zestawy, które w Agile, Scrumie są nazywane Przypadkami Użycia (Use Cases) i mają na celu udzielenie odpowiedzi na pytanie: „Co z oprogramowaniem zrobią użytkownicy?”.
Przypadki Użycia stanowią swoisty opis całych sekwencji interakcji, jakie zachodzą między systemem (aplikacją webową lub mobilną) a użytkownikiem.
Use Cases, Przypadki Użycia opisują sposoby osiągania celów przez użytkowników.
Odwołajmy się do kolejnego przykładu.
Przypadkiem Użycia może być sposób tworzenia konta klienta w sklepie internetowym.
W ramach interakcji koniecznych do jego utworzenia, zazwyczaj wymagane jest wprowadzenie do pól formularzy danych, stworzenie hasła, zweryfikowanie adresu e-mail, podanie danych karty kredytowej.
A wszystkie te działania zazwyczaj są rozbijane na etapy. Wszystkie te działania da się wyrazić za pomocą Historyjek Użytkownika, które łącznie stworzą logiczny, spójny Przypadek Użycia (Use Case).
Powyższe ustalenia wymagają jednak dodania istotnej uwagi, którą poczyniła Yvette Francino w artykule pt. “User Story”.
Otóż, jak słusznie zauważa Francino, Historyjki Użytkownika nie powinny być traktowane jako zamienniki Przypadków Użycia, ani tym bardziej jako zamienniki dokumentacji wymagań funkcjonalnych.
Zdecydowanie Historyjki Użytkownika powinny być traktowane jako narzędzie służące do priorytetyzacji dodawania funkcjonalności w ramach kolejnych Sprintów.
User Story można także używać jako punkt wyjścia do ustalania kompletu wymagań, jakie powinien spełniać dany produkt cyfrowy.
Taki też był pierwotny sens User Stories, które początkowo były zapisywane na karteczkach samoprzylepnych i przylepiane na ogólnodostępnych tablicach
Dzięki temu wszyscy członkowie zespołu mieli do nich dostęp i mogli swobodnie za ich pomocą dokonywać planowania prac.
Aktualnie User Stories najczęściej przybierają formę digitalną, są zapisywane w dedykowanych narzędziach (np. Jira), jako element Backlogu Produktu (Product Backlog), do którego trafiają po spotkaniach Sprint Planningowych.
No dobrze, ale kto powinien pisać User Stories? Czy jest to zadanie przypisane do konkretnej roli, specjalizacji w ramach zespołu scrumowego (Scrum Team)?
Co do zasady, w ramach frameworku Scrum nie ma przypisanej do tego zadania jednej osoby. Każdy może pisać Historyjki Użytkownika.
Z pewnością dobrą praktyką jest zespołowe wykonywanie tego zadania, tworzenie ich w oparciu o skumulowaną wiedzę, doświadczenia całego zespołu scrumowego oraz interesariuszy.
Format User Story, czyli jak napisać porządną Historyjkę Użytkownika
Wprawdzie User Story jest pisane w języku naturalnym, ale by spełniać swe zadania nie może być zapisem przypadkowych zdań.
Innymi słowy Historyjki Użytkownika należy zapisywać zgodnie z przyjętym formatem oraz wzorem.
Odpowiednia struktura pozwala uchwycić istotę i zminimalizować ryzyko, że napisane User Story będzie niejednoznaczne, niekomunikatywne, niekonkretne i tym samym umiarkowanie lub w ogóle nieprzydatne.
Trzymanie się struktury pozwala także łatwiej uchwycić sens tego zadania i uczynić je możliwie najbardziej użytecznym dla zespołu scrumowego - zarówno projektowego, jak również developerskiego.
Formuła, w jakiej wyrażane jest User Story, najczęściej przyjmuje postać trzech elementów, które stanowią odpowiedź na pytania:
- Jako Persona / Rola … (Kto?)
- chcę / potrzebuję …. (Co?)
- aby / ponieważ …. (Dlaczego?).
Przykładowo: Jako klient sklepu internetowego chcę mieć możliwość założenia konta, aby nie musieć wprowadzać przy kolejnych zakupach danych teleadresowych.
Historyjkę Użytkownika można także wyrazić za pomocą wzorca, w którym określa się rolę, cechę oraz korzyść:
- Jako… (Persona, Rola)
- chcę… (Określenie sposobu działania funkcji)
- aby… (Wskazanie korzyści i/lub wartości)
Przykładowo: Jako zalogowany użytkownik chcę, by sklep automatycznie uzupełniał moje dane teleadresowe przy kolejnych zakupach, abym mógł zaoszczędzić czas.
Wskazując Personę lub Rolę, która chce korzystać z danej funkcji należy pamiętać, by była ona zgodna z opisem Persony, reprezentującej dany segment grupy docelowej, by była możliwie wiernym odbiciem tego, kim jest realny klient i/lub użytkownik.
Na tyle, na ile to możliwe wyobrażenie użytkownika powinno być realistyczne. Nie może być abstrakcyjnym bytem, który po prostu czegoś w systemie używa.
User Story mają wyrażać realne potrzeby, korzyści - i warto pamiętać, że ich uzasadnienie nie zawsze bywa logiczne, spójne, czy oczywiste.
Pisząc User Story zawsze trzeba wiedzieć, jakie konkretnie cechy i charakterystyki posiada dany użytkownik. Co go determinuje, zachęca, interesuje, co uznaje za atrakcyjne, użyteczne.
Na przykład, wiedząc, w jakim jest wieku, gdzie mieszka, jakiej jest płci, jakie ma zainteresowania, jaki zawód wykonuje, jakie ma doświadczenia i kompetencje cyfrowe wiemy - wprawdzie nadal dość ogólnie - czego może oczekiwać od systemu.
Im konkretniejsze jest wyobrażenie o modelowym użytkowniku, tym bardziej trafione będą jego potrzeby, jakie chcemy zaspokoić, a które są wyrażane w środowej części User Story, która odpowiada na pytanie - “Co?”.
Określenie korzyści, wartości i/lub zrozumienie, dlaczego dana funkcja jest dla użytkownika ważna, konieczna, potrzebna przysparza twórcom User Stories najwięcej problemów.
Już z racji tego, że potrzeby można zaspokajać na wiele sposobów. Lub z racji tego, że dana funkcjonalność w aplikacji webowej lub mobilnej może - i dość często rzeczywiście zaspokaja - kilka potrzeb jednocześnie.
Znalezienie tej, której użytkownik szuka najbardziej jest zadaniem, które wymaga jednocześnie sporej wiedzy o grupie docelowej (także pozyskanej w badaniach użyteczności), ale także pewnego doświadczenia i empatii.
Pisząc User Stories trzeba także pamiętać, że można je tworzyć na różnych poziomach szczegółowości.
Co do zasady, im Historyjka Użytkownika jest ogólniejsza, tym więcej zawiera w sobie historyjek bardziej szczegółowych, które tworzą spójną całość zwaną Epiką.
Epiki, a więc zbiory powiązanych ze sobą Historyjek Użytkownika, zazwyczaj nie są możliwe do wdrożenia w ramach jednego Sprintu, dlatego dobrą praktyką jest dzielenie ich na mniejsze User Stories.
Tworząc Historyjki Użytkownika bardzo istotne jest uwzględnianie:
- definicji Gotowe - Definition of Done
- zadań głównych i dodatkowych
- wszystkich Person, Ról - należy w szczególności sprawdzać, czy dana Historyjka jest rzeczywiście trafna dla wszystkich - co nie jest wykluczone i niemożliwe, ale też nie jest oczywiste
- realnych oczekiwań, potrzeb, motywacji użytkowników, klientów, które można poznać za pomocą badań UX
- poziomu złożoności User Story, która determinuje czas konieczny na jej wdrożenie w ramach jednego Sprintu.
Szerzej o sposobach, technikach walidowania, oceniania, akceptowania User Stories pisaliśmy w artykule pt. “Kryteria akceptacji User Story”.
Tytułem przypomnienia dodamy tylko, że kryteria akceptacji, warunki satysfakcji pozwalają rozstrzygać, czy dana Historyjka Użytkownika spełnia różnorodne oczekiwania, także biznesowe.
Odnosząc się do naszego przykładu z Historyjką Użytkownika dotyczącą rejestracji konta, jednym z kryteriów akceptacji powinno być określenie, jakie dane są oczekiwane do wprowadzenia, jakie są sposoby walidowania tych danych, jakie hinty, alerty powinny być oferowane użytkownikowi.
Podstawowe cele tworzenia Historyjek Użytkownika w Scrumie
Historyjki Użytkownika we frameworku Scrum stanowią podstawę zadań wykonywanych w ramach danego Sprintu.
Historyjki Użytkownika, jak pisaliśmy wyżej, stanowią także najmniejszą jednostkę pracy, dzięki czemu stanowią także punkt odniesienia do planowania prac.
Zarówno w sensie czasu ich trwania, kolejności, jak również zależności między nimi zachodzących.
Im większe doświadczenia z Historyjkami Użytkownika posiadają zespoły scrumowe, tym dokładniej potrafią oszacować czas pracy, planować Sprinty oraz prognozować przebieg projektu.
User Stories są doceniane także za:
- promowanie oraz usprawnianie współpracy między członkami zespołu scrumowego
- fokusowanie uwagi na zadaniach i jednocześnie stojących za nimi użytkownikach, których problemy, potrzeby dana Historyjka reprezentuje i pozwala rozwiązać i zaspokoić
- wspieranie myślenia krytycznego, kreatywnego, nieszablonowego
- mobilizujący, nagradzający charakter - ukończona Historyjka ma pozytywny wpływ na motywację do pracy, dostrzeganie jej celu, sensu.
Christiaan Verwijs w artykule pt. “The purpose of User Stories in Scrum” wskazał w bardzo wyczerpujący sposób kolejne zalety, jakie płyną dla zespołów scrumowych z korzystania z User Stories.
Historyjka Użytkownika zdaniem Verwijsa służy także do:
- doskonalenia, optymalizowania funkcjonalności pod kątem sposobów jej działania, efektów, jakie przynosi, celów, jakie pozwala osiągnąć
- uzyskania szerszej perspektywy (Big Picture), dzięki czemu zespół jest w stanie dostrzec, co aplikacja będzie w stanie zrobić / czego nie będzie w stanie zrobić dla użytkowników
- priorytetyzowania zadań
- skrótowego, komunikatywnego, prostego przekazywania kluczowych cech funkcjonalności, co w pewnym sensie przeciwdziała paraliżującym praktykom tworzenia rzeczywistej specyfikacji - przy czym User Stories nie mogą być traktowane jako ekwiwalenty specyfikacji.
Dlaczego jeszcze warto tworzyć Historyjki Użytkowników w Scrumie?
Bowiem reprezentując jednostkę pracy, a jednocześnie mogąc być tworzone i dodawane do Backlogu Produktu (Product Backlog) w dowolnym momencie są możliwe do wykonywania w momencie, w którym zespół scrumowy uzna za optymalny.
Przypomnijmy, że w ramach frameworku Scrum, Backlog Produktu (Product Backlog) jest listą funkcjonalności, które mają być rozwijane w produkcie cyfrowym.
Historyjki Użytkowników stały się optymalną i bardzo popularną formą ustalania elementów rejestru produktu.
Możliwość planowania Sprintów, włączania do danego Sprintu, danej User Story pozwala prowadzić projekt w sposób o wiele bardziej elastyczny i dostosowany do zmieniających się potrzeb.
Historyjki pozwalają także szacowanie złożoności pracy, czasu, jaki jest konieczny na jej wykonanie.
Estymowanie czasu pracy koniecznego dla danego elementu w Backlogu (Product Backlog) najczęściej jest dokonywane za pomocą różnego rodzaju technik (np. ciągu Fibonacciego).
Innymi słowy, User Stories w frameworku Scrum pozwalają lepiej kontrolować przebieg projektu, zarządzać zadaniami, nadawać im rangi i priorytety, szacować pracę, motywować członków zespołu.
Nie można także zapominać, że Agile, Scrum są ufundowane na konkretnych wartościach, a User Stories stanowią ich przejaw.
Agile traktuje ludzi, użytkowników, ich interakcje priorytetowo, stąd też Historyjka Użytkownika pozwala dostrzegać czysto ludzki wymiar interakcji, ludzkie potrzeby, stojące za funkcjonalnościami.
Także zespół scrumowy korzysta ze zorientowanego na człowieka podejścia. Czytając User Story wyrażoną naturalnym językiem jest w stanie lepiej zrozumieć kontekst, korzyści, potrzeby.
User Stories nie tyle pozwalają zaoferować użytkownikom końcowym narzędzia, techniczne rozwiązania, ile oferują konkretną wartość, która wprawdzie wynika z “technikaliów”, ale się do nich nie sprowadza.
Scrum User Story. Podsumowanie
- Metodyki zwinne są sfokusowane na potrzebach użytkownika końcowego.
- Oczekiwania, doświadczenia, kompetencje, możliwości, przyzwyczajenia użytkownika końcowego powinny być w szczególności uwzględniane w procesie projektowania, wdrażania, rozwijania i udoskonalania produktu cyfrowego.
- User Story, Historyjka Użytkownika przede wszystkim pozwala określić, czego użytkownik chce oraz dlaczego tego chce.
- Wyjątkowość User Stories polega na szczególnej perspektywie przekazania oczekiwań.
- Chodzi nie o to, co system powinien oferować, co powinien posiadać, ale co może dla użytkownika zrobić.
- W metodyce Agile, we frameworku Scrum, User Story to po prostu krótki - jedno-, dwuzdaniowy - nieformalny, prosty opis tego, co użytkownik końcowy chce zrobić, osiągnąć za pomocą oprogramowania.
- User Story to opis celu, jaki chce uzyskać, wartości, jaka jest dla niego ważna i cenna, korzyści, jakie zamierza odnieść.
- W Scrumie Historie Użytkownika reprezentują także najmniejszą jednostkę pracy, jaką w ramach danego projektu należy wykonać.
- Historia Użytkownika powinna być zapisywana zgodnie z przyjętym formatem oraz wzorem.
- Historyjki Użytkownika we frameworku Scrum stanowią pewne wymaganie, podstawę zadań wykonywanych w ramach danego Sprintu.
- Agile traktuje ludzi, użytkowników, ich interakcje priorytetowo, stąd też Historyjka Użytkownika pozwala dostrzegać czysto ludzki wymiar interakcji, ludzkie potrzeby, stojące za funkcjonalnościami.
