INVEST – czyli jak pisać dobre User Story

W jednym z poprzednich artykułów opisałem technikę User Story. Wyraziłem również moją opinię na temat tego, do czego warto je wykorzystywać, a do czego kompletnie się nie nadają. Historyjki Użytkownika wydają się techniką bardzo prostą w użyciu ze względu na swoją krótką i zwięzłą formę oraz wykorzystanie szablonu składni. Czy jednak rzeczywiście są tak banalne w użyciu? Oczywiście, że nie.

Spotykam się często z User Stories pisanymi na szybko, bez dokładnego przemyślenia, byle tylko spełnić wymagania wynikające z przyjętego szablonu. Oczywiście ma to katastrofalne skutki. Jeśli jedynym celem autora jest wpasowanie się w szablon bo „tak kazali” lub ” taki mamy standard”, to oznaczy, że nie warto zadawać sobie trudu i lepiej opisać wymagania w inny sposób, chociażby używając języka naturalnego.

INVEST – cechy dobrego User Story

Jak zatem pisać User Story aby było to efektywne i użyteczne? Warto zwrócić szczególną uwagę na ich jakość. Aby to ułatwić, powstał pewien użyteczny skrót, tworzący łatwe do zapamiętania, angielskie słowo INVEST.

I jak Independent

User Stories powinny być od siebie niezależne. Oznacza to, że mogą być zrozumiane, zaimplementowane oraz mogą dostarczać wartości, niezależnie od siebie.

Oczywiście nie oznacza to braku jakichkolwiek relacji. Tak jak pomiędzy wymaganiami opisanymi w dowolny sposób, tak również pomiędzy User Stories mogą pojawiać się relacje. Mogą one wskazywać, że dana Historyjka Użytkownika musi być zaimplementowana przed inną lub zaimplementowanie jednej znacząco zmniejszy wysiłek zaimplementowania innej. Chodzi natomiast o to, by User Story, stanowiło pewną, odrębną i logiczną całość.

Analogią jest tutaj budowa domu i wylewanie fundamentów oraz stawianie ścian. Oczywiście jest między nimi pewna relacja i jedna czynność musi być wykonana przed drugą, jednak stanowią odrębne i logicznie wyróżnialne etapy budowy.

Antyprzykładem byłoby przedstawienie w ramach oddzielnych historyjek montażu kaloryferów oraz rur centralnego ogrzewania. Elementy te zdecydowanie samodzielnie nie dostarczają wartości.

N jak Negotiable

User Story powinno być negocjowalne, czyli pozostawiać przestrzeń na dyskusje i negocjacje co do sposobu dostarczenia rozwiązania. Niepoprawnym jest tworzenie zbyt szczegółowych i „technicznych” User Story narzucających zespołom deweloperskim dokładny sposób tworzenia rozwiązania. Zabija to kreatywność i naraża na ryzyko pominięcia potencjalnie lepszego rozwiązania.

V jak Valuable

Poprawne User Story wyraża wartość, która będzie dostarczona poprzez jego zaimplementowanie. Sama jego konstrukcja narzuca, iż powinniśmy wskazać Kto? Co? Po co? i właśnie to „Po co?” jest szczególnie ważne, gdyż wyraża sedno potrzeby biznesowej i dostarczanej wartości. Jeśli natomiast implementacja Historyjki Użytkownika nie dostarcza żadnej wartości, to po co się nią zajmować? Oznacza to jedynie poniesienie kosztu implementacji, bez wyraźnego zysku, a więc marnotrawstwo.

E jak Estimable

Poprawnie określone User Story musi być możliwe do „oszacowania” to znaczy określenia wysiłku niezbędnego do jego zaimplementowania. Nie chodzi tu oczywiście o dokładne wyceny w dniach lub co gorsza godzinach a o estymacje relatywne, wykorzystujące relatywne jednostki (jak np. Story Pointy) i bazujące na wcześniejszych doświadczeniach zespołu deweloperskiego. Estymację znacząco ułatwia zdefiniowanie jasnych i jednoznaczych kryteriów akceptacji.

S jak Sized Appropriately

Właściwie to im „mniejsze” User Story tym lepiej, oczywiście w granicach rozsądku. Granicą sensownej wielkości (wynikającej z relatywnej wyceny) jest możliwość dostarczenia w ramach jednej iteracji (Sprintu). Jeśli z estymacji jasno wynika, że Historyjki Użytkownika nie uda się dostarczyć w ramach iteracji, należy ją podzielić na mniejsze elementy.

T jak Testable

Tak jak każde wymaganie i jego definicja, tak i również wymaganie opisane w postaci User Story musi być testowalne. Oznacza to mniej więcej tyle, że musi istnieć możliwość obiektywnego sprawdzenia czy zostało zaimplementowane i dostarczyło zakładaną wartość, określonemu interesariuszowi. Innymi słowy musi być możliwy do zdefiniowania i przeprowadzenia test, który to weryfikuje w jednoznaczny sposób.

Moje rekomendacje

  • Używaj User Story świadomie, zwracając szczególną uwagę na ich jakość
  • Zapamiętaj (lub miej pod ręką) listę cech dobrego User Story, składających się na akronim INVEST
  • Definiując Historyjki Użytkownika staraj się rozważyć i uwzględnić wszystkie opisane cechy
  • Zwracaj uwagę na opisane cechy przeglądając User Story definiowane przez innych analityków (robiąc Review)