Blog

Scrum Guide | 20. INVEST, czyli 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:

  1. Wprowadzenie
  2. N jak Niezależna
  3. N jak Negocjowalna
  4. W jak Wartościowa lub Werykalna
  5. S jak Szacowalna
  6. M jak Mała
  7. T jak Testowalna
  8. 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.

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ć:

  1. Niezależna od innych User Stories. Po to, by mogła być modyfikowana lub usunięta z Backlogu Produktu, jeśli zaistnieje taka potrzeba.
  2. Negocjowalna. Powinna określać co zostanie zrobione, pozostawiając wybór sposobu Developerom.
  3. Wartościowa, czyli uzasadniająca biznesowy sens modyfikacji Produktu. Lub też Werykalna, czyli prezentująca nową cechę Produktu widoczną dla Użytkownika.
  4. Szacowalna, czyli posiadająca dającą się określić wielkość i kryterium ukończenia.
  5. Mała na tyle, aby mogła zostać ukończona w jednym Sprincie.
  6. 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ść.

Caroline Becker

As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.

Recent Posts

7 błędów poznawczych, które wpływają na naszą produktywność

Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…

2 lata ago

Jak obniżyć koszty rekrutacji?

Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…

2 lata ago

Elastyczne plany pracy i milenijni pracownicy

Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…

2 lata ago

Zalety pracy zdalnej dla pracowników i pracodawców

Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…

2 lata ago

O działaniu i biznesowych zastosowaniach voicebotów | AI in business #10

Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…

2 lata ago

Jak wirtualny asystent AI może pomóc w rozwoju Twojej firmy? | AI in business #11

“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…

2 lata ago