INVEST - czyli metoda jak stworzyć dobre User Story

INVEST jest metodą tworzenia dobrych User Stories. Pozwala sprawdzić, czy mają odpowiednio sformułowaną treść, czy odnoszą się do wartości biznesowej Produktu. A także, czy ich wielkość i użyteczność zostały odpowiednio dobrane.

INVEST – omówione zagadnienia:

Wprowadzenie
N jak Niezależna
N jak Negocjowalna
W jak Wartościowa lub Werykalna
S jak Szacowalna
M jak Mała
T jak Testowalna
Podsumowanie

INVEST – wprowadzenie

INVEST to akronim stworzony przez Billa Wake w 2003 roku. Każda jego litera oznacza początek słowa, które charakteryzuje dobrą User Story. Według zasady INVEST każda User Story powinna być:

Niezależna (Independent)
Negocjowalna (Negotiable)
Wartościowa (Valuable)
Szacowalna (Estimable)
Mała (Small)
Testowalna (Testable)

Więcej na temat tego, czym jest User Story pisaliśmy w osobnym artykule. Tutaj wspomnimy tylko, że jest ona zwięzłym opisem nowej funkcjonalności Produktu napisanym w przystępnym języku.

Creating the best User Story with INVEST

N jak Niezależna

Pierwszą cechą dobrej User Story jest jej niezależność. Oznacza to, że jej opis i charakterystyka powinny być zrozumiałe bez odniesienia do innych User Stories. Ale przede wszystkim to, że jej realizacja nie powinna być bezpośrednio uzależniona od realizacji innych User Stories. Nie będzie to oczywiście pełna niezależność. Tworzenia Produktu nie da się bowiem podzielić na zupełnie odrębne moduły. Jednak ważne by pamiętać o zachowaniu możliwie dużej samodzielności User Stories. Dzięki temu nawet, gdy jedna z nich nie wejdzie do fazy realizacji, albo zostanie znacząco zmodyfikowana, pozostałe User Stories nie będą musiały być modyfikowane. Co do zasady, User Story powinna więc stanowić odrębną i logiczną całość.

N jak Negocjowalna

User Story powinna być negocjowalna. Oznacza to, że wyznacza ona Cel, a nie sposób dojścia do niego.

Innymi słowy, określa oczekiwaną cechę Produktu, a nie techniczne rozwiązanie, które powinno zostać wdrożone.

Negocjowanie User Story ma miejsce pomiędzy Product Ownerem a Zespołem Developerskim. Product Owner proponuje realizację pewnej funkcjonalności Produktu, czyli mówi „Co” zostanie zrobione. Natomiast do Developerów należy odpowiedź na pytanie „Jak”. Czyli wynegocjowanie konkretnych sposobów rozwiązania problemu postawionego w User Story.

W jak Wartościowa lub Wertykalna

W skrótowcu INVEST litera V jest odczytywana dwa sposoby, jako:

Wartościowa (Valuable)
Wertykalna (Vertical)

Oba rozwinięcia dają istotną charakterystykę dobrej User Story. Dlatego zdecydowaliśmy wyjaśnić, co oznacza każde z nich.

Wartościowa

Wartościowa User Story to taka, która jasno uzasadnia biznesowy sens wprowadzanej modyfikacji. Innymi słowy, trafnie odpowiada na pytanie Po co? dana modyfikacja powinna zostać wprowadzona. I dlaczego jest to ważne z punktu widzenia Interesariuszy.

Wertykalna

Rozwinięcie litery V jako Wertykalna zostało zaczerpnięte z metodyki Agile. Wertykalna User Story zawiera nową cechę Produktu widoczną dla Użytkownika. Czyli nie koncentruje się na horyzontalnej „poprawie funkcjonowania” w wybranej warstwie Produktu. Przeciwnie, dobudowuje do niego kolejne „piętro”.

Innymi słowy, User Story opisuje, w jaki sposób zmodyfikować całość działania Produktu odpowiadając na pytanie Co konkretnie zostanie ulepszone? Oznacza to również, że każda funkcjonalność Produktu nabudowuje się na już istniejących rozwiązaniach.

S jak Szacowalna

Dobra User Story powinna być szacowalna. Oznacza to, że musi jasno określać zakres modyfikacji, które trzeba wprowadzić w produkcie, aby User Story została uznana za zrealizowaną. Dzięki temu Zespół Developerski jest w stanie określić czas i nakłady pracy konieczne do jej wykonania.

Zakres i trudność zadania są najczęściej szacowane w jednostkach nazywanych Story Points. Są one relatywne. A każdy Zespół Developerski wypracowuje w praktyce wartość Story Point bazując na wcześniejszych doświadczeniach.

W osobnych artykułach opisaliśmy więcej na temat Prędkości Zespołu Developerskiego i sposobach jej mierzenia.

M jak Mała

User Story przyjęta do realizacji przez Zespół Developerski powinna być krótka. Czyli czas jej planowanej realizacji powinien być nie dłuższy niż czas trwania jednego Sprintu. Jeśli Developerzy podczas Planowania Sprintu odkryją, że User Story zaproponowana przez Product Ownera jest zbyt długa, powinni podzielić ją na możliwie niezależne od siebie części.

T jak Testowalna

Pod ostatnią literą akronimu INVEST kryje się słowo testowalna. Oznacza ono, że modyfikacja Produktu opisana w User Story musi być konkretna i możliwa do sprawdzenia. Innymi słowy, powinna istnieć możliwość weryfikacji, czy rozwiązanie zaimplementowane przez Developerów dostarczyło zakładaną wartość określonemu Interesariuszowi.

Podsumowanie

INVEST to akronim opisujący dobrze napisaną User Story. Powinna ona być:

Niezależna od innych User Stories. Po to, by mogła być modyfikowana lub usunięta z Backlogu Produktu, jeśli zaistnieje taka potrzeba.
Negocjowalna. Powinna określać co zostanie zrobione, pozostawiając wybór sposobu Developerom.
Wartościowa, czyli uzasadniająca biznesowy sens modyfikacji Produktu. Lub też Werykalna, czyli prezentująca nową cechę Produktu widoczną dla Użytkownika.
Szacowalna, czyli posiadająca dającą się określić wielkość i kryterium ukończenia.
Mała na tyle, aby mogła zostać ukończona w jednym Sprincie.
Testowalna tak, aby można było określić z całą pewnością, że została zrealizowana.

Sprawdź również – Najczęstsze błędy popełniane przy pisaniu User Story

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty

Przerwa konserwacyjna

Scrum Guide | 20. INVEST, czyli jak stworzyć dobre User Story