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.

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

  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.

Scrum Guide | 20. INVEST, czyli jak stworzyć dobre User Story caroline becker avatar 1background

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ść.

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?