User Story – jak je dzielić gdy są za duże?

W poprzednim artykule opisałem cechy dobrego User Story, których pierwsze litery składają się na łatwe do zapamiętania słowo INVEST. Jedną z tych cech było „Sized Appropriately”. Wspomniałem, że granicą wielkości User Story jest możliwość implementacji w ramach jednej iteracji. Jeśli nie jest to możliwe, mamy do czynienia z tzw. Epikiem (ang. Epic) i należy go podzielić.

Najważniejszą zasadą jest to, aby po podziale, nowo powstałe User Stories niezależnie dostarczały wartości interesariuszom. Oczywiście warto zwrócić również uwagę na pozostałe cechy tworzące INVEST. Wskazane jest aby dzielić Historyjki Użytkownika wertykalnie, tzn. dzielić je względem funkcjonalności. Innymi słowy tak, aby każde z nich dało się zaprezentować niezależnie finalnym użytkownikom.

Podział horyzontalny, wynikający z kolejnych kroków implementacji, np. przygotowanie struktury danych, implementacja logiki biznesowej i opracowanie interfejsu użytkownika, w ramach oddzielnych story, jest absolutnie niewskazany. Jeszcze gorszym pomysłem jest podział User Story względem kolejnych faz procesu tworzenia oprogramowania, czyli np. projektowanie, implementacja i testowanie opisane w ramach oddzielnych Historyjek Użytkownika.

Sposoby podziału User Story

Poniżej prezentuję kilka sposobów podziału zbyt dużych (niemożliwych do zaimplementowania w jednej iteracji) User Story. Oczywiście sposobów jest więcej, a jedynym ograniczeniem jest tutaj kreatywność Analityka Biznesowego.

W przedstawionych poniżej przykładach skupiam się jedynie na jednym z elementów User Story, a mianowicie Statement of Value i pomijam pozostałe.

Według kroków procesu

Jeśli proces składa się z wielu kroków, każdy z nich możemy opisać za pomocą oddzielnej Historyjki Użytkownika. Banalnym przykładem może tu być proces składania zamówienia w sklepie internetowym. Może się on składać np. z dodawania towaru do koszyka, wyboru metody płatności, wyboru metody dostawy i podsumowania oraz potwierdzenia zamówienia. Cały proces może być opisany jako ogólna Historyjka użytkownika:

Jako klient chcę złożyć zamówienie w sklepie internetowym, aby otrzymać wybrane przeze mnie produkty.

Podane powyżej przykładowe User Story byłoby zapewne dość skomplikowane i czasochłonne w implementacji. Możemy rozbić je względem przedstawionych wyżej kroków procesu:

Jako klient chcę dodać towary do koszyka, aby wskazać które towary zamierzam kupić.

Jako klient chcę wybrać metodę płatności, aby zapłacić w preferowany przeze mnie sposób.

Jako klient chcę wybrać metodę dostawy, aby otrzymać przesyłkę w preferowany przeze mnie sposób.

Jako klient chcę zobaczyć podsumowania, aby móc przejrzeć szczegóły i uniknąć ewentualnej pomyłki.

Jako klient chcę potwierdzić zamówienie, aby przesłać do sklepu jego finalną wersję i otrzymać zamówione produkty.

Według kryteriów akceptacji

Zdarza się, że User Story zawiera wiele kryteriów akceptacji. W takim przypadku sensowne bywa jego podzielenie względem pewnych podzbiorów kryteriów akceptacji.

Pozostając w tematyce sklepu internetowego, możemy wyobrazić sobie Historyjkę Użytkownika dotyczącą składania zamówienia i zawierającą sporo kryteriów akceptacji. Kryteria te mogą mówić o: możliwości zamówienia wielu towarów, możliwości edytowania listy towarów dodanych „do koszyka”, możliwości anulowania zamówienia (opróżnienia „koszyka”), wyświetlania aktualnej wartości „koszyka” etc. Możliwy jest oczywiście podział na kilka niezależnych User Stories bazując właśnie na wyłączaniu poszczególnych kryteriów akceptacji.

Według zakresu danych

Podział według zakresu danych jest możliwy w przypadku User Stories mówiących o wyświetlaniu lub przetwarzaniu skomplikowanych struktur lub dużych ilości danych. Weźmy pod uwagę wyświetlanie profilu użytkownika w sklepie internetowym. Profil taki może zawierać: nazwę użytkownika, podstawowe dane (imię i nazwisko, adres e-mail, telefon), wiele adresów do wysyłki, dane do wystawiania faktur, preferowaną formę płatności, preferowany sposób dostawy etc.

Jeśli User Story dotyczące wyświetlania (np. na interfejsie użytkownika) wszystkich dostępnych danych jest zbyt duże, możemy dane te pogrupować i stworzyć zbiór oddzielnych User Stories odpowiadających poszczególnym grupom danych.

Według operacji

Typowym zbiorem operacji wykonywanych na danych jest tzw. CRUD (ang. Create, Read, Update, Delete). Jeśli zestaw operacji, wykonywanych na danych obejmuje CRUD (lub jego podzbiór), możemy rozdzielić poszczególne operacje na osobne Historyjki Użytkownika. Jeśli np. użytkownik sklepu internetowego może podawać adres dostawy (lub wiele adresów), możliwy jest podział na osobne User Stories obejmujące tworzenie adresów i ich wyświetlanie, usuwanie oraz edytowanie.

Według wymagań niefunkcjonalnych

Wymagania niefunkcjonalne wydają się być szczególnie „wdzięczne” pod względem podziału User Story na ich podstawie. Można tu podać wiele potencjalnych przykładów. Jednym z nich mogą być wymagania dotyczące wydajności. Załóżmy, że mamy wymaganie, iż raport ma się generować w mniej niż 5 sekund. Oczywiście przy określonej ilości danych i określonych warunkach. W takiej sytuacji, możemy opisać proces generowania raportu w ramach jednego User Story, a jego optymalizację w oddzielnym.

Innym przykładem może być dostępność interfejsu użytkownika w wielu językach bądź możliwość korzystania z systemu na wielu platformach (np. Android i iOS). Każdy język interfejsu i obsługę na każdej z platform możemy opisać za pomocą oddzielnego User Story.

Wyłączanie wymagań niefunkcjonalnych do osobnego User Story bywa jednak ryzykowne. Postępując w ten sposób zwiększamy prawdopodobieństwo, że nie zostaną one nigdy zaimplementowane.

Oczywiście pomysłów na podział Historyjek Użytkownika może być dużo więcej. Przedstawione powyżej to jedynie przykłady, które nie wyczerpują pełnej listy możliwości.

Moje rekomendacje

• Jeśli z estymacji wynika, iż User Story nie jest możliwe do zaimplementowania w jednej iteracji, podziel je
• Dziel User Story w sposób wertykalny, tak by każde z nich dostarczało wartości i było możliwe do zaprezentowania
• Staraj się, aby User Story powstałe po podziale, posiadały cechy tworzące skrót INVEST