Przewodnik po Scrumie | 20. INVEST – Tworzenie najlepszej historii użytkownika

Opublikowany: 2022-05-21

INVEST to sposób na tworzenie dobrych User Stories. Pozwala to sprawdzić, czy mają właściwie sformułowane treści i czy odnoszą się do wartości biznesowej Produktu. A także czy ich rozmiar i użyteczność zostały odpowiednio dobrane.

Tworzenie najlepszego User Story z INVEST – spis treści:

  1. Wstęp
  2. Ja dla Niezależnego
  3. N jak do negocjacji
  4. V jak wartościowy lub pionowy
  5. E jak szacowany
  6. S jak małe
  7. T jak testowalny
  8. Streszczenie

Wstęp

INVEST to akronim stworzony przez Billa Wake'a w 2003 roku . Każda jego litera oznacza początek słowa, które charakteryzuje dobrą historię użytkownika. Zgodnie z zasadą INVEST, każde User Story powinno być:

  • Niezależny
  • Do negocjacji
  • Wartościowy
  • Godny szacunku
  • Mały
  • Testowalne

Więcej o tym, czym jest User Story, pisaliśmy w osobnym artykule. W tym miejscu nadmienimy tylko, że jest to zwięzły opis nowej funkcjonalności Produktu napisany przystępnym językiem.

Creating the best User Story with INVEST

Ja dla Niezależnego

Pierwszą cechą dobrej historii użytkownika jest jej niezależność. Oznacza to, że jego opis i charakterystyka powinny być zrozumiałe bez odwoływania się do innych historyjek użytkownika. Ale przede wszystkim jego realizacja nie powinna korelować z innymi User Stories. Oczywiście nie będzie to pełna niezależność. Nie możesz podzielić tworzenia Produktu na całkowicie oddzielne moduły. Należy jednak pamiętać o tym, aby Historie użytkowników były jak najbardziej niezależne. Dzięki temu nawet jeśli jeden z nich nie wejdzie w fazę wdrożenia lub zostanie znacząco zmodyfikowany, to pozostałego nie będzie trzeba modyfikować. Co do zasady User Story powinna stanowić odrębną i spójną całość.

N jak do negocjacji

Historia użytkownika powinna podlegać negocjacjom. Oznacza to, że wyznacza Cel, a nie drogę do niego.

Innymi słowy, określa oczekiwaną cechę Produktu, a nie rozwiązanie techniczne do wdrożenia.

Negocjacje User Story odbywają się między Właścicielem Produktu a Zespołem Deweloperskim. Właściciel Produktu proponuje wdrożenie określonej funkcjonalności Produktu, czyli mówi „Co” zrobić. Deweloperzy odpowiadają za odpowiedź na pytanie „Jak”. Czyli negocjowanie konkretnych sposobów rozwiązania problemu przedstawionego w User Story.

V jak wartościowy lub pionowy

W akronimie INVEST litera V oznacza dwie cechy:

  • Wartościowy
  • Pionowy

Oba ujawniają kluczowe cechy dobrego User Story. Dlatego postanowiliśmy wyjaśnić, co każdy z nich oznacza.

Wartościowy

Cenny User Story uzasadnia biznesowy cel modyfikacji. Innymi słowy, trafnie odpowiada na pytanie, dlaczego wprowadzać modyfikację i dlaczego jest to ważne z punktu widzenia interesariuszy.

Pionowy

Druga cecha; Vertical wywodzi się z metodologii Agile. Pionowa Historyjka Użytkownika zawiera nową cechę Produktu widoczną dla Użytkownika. Oznacza to, że nie skupia się na horyzontalnej „poprawie wydajności” w wybranej warstwie Produktu. Wręcz przeciwnie, dodaje do niego kolejną „warstwę”.

Innymi słowy, User Story opisuje, jak zmodyfikować ogólne działanie Produktu, odpowiadając na pytanie Co konkretnie poprawić? Oznacza to również, że każda funkcjonalność Produktu opiera się na istniejących rozwiązaniach.

E jak szacowany

Dobra historia użytkownika powinna dać się oszacować. Oznacza to, że musi jasno określić zakres modyfikacji, jakie należy wprowadzić w produkcie, aby Historię Użytkownika można było uznać za kompletną. Pozwala to Zespołowi Deweloperskiemu określić czas i wysiłek potrzebny do jego ukończenia.

Zakres i trudność zadania szacowane są zazwyczaj w jednostkach zwanych Story Points. Są względne. Każdy Zespół Deweloperski wypracowuje wartość Story Point w praktyce na podstawie wcześniejszych doświadczeń.

W osobnych artykułach omówiliśmy więcej o prędkości zespołu deweloperskiego i sposobach jej mierzenia.

user story

S jak małe

User Story przyjęta do realizacji przez Zespół Deweloperski musi być zwięzła. Oznacza to, że nie powinien trwać dłużej niż jeden sprint. Jeśli Deweloperzy podczas Planowania Sprintu odkryją, że Historyjka Użytkownika proponowana przez Właściciela Produktu jest zbyt długa, powinni podzielić ją na możliwie niezależne części.

T jak testowalny

Ostatnia litera akronimu INVEST oznacza testable. Oznacza to, że modyfikacja Produktu opisana w User Story musi być wodna i możliwa do zweryfikowania. Innymi słowy, powinno być możliwe zweryfikowanie, czy rozwiązanie wdrożone przez Developerów przyniosło założoną wartość konkretnemu Interesariuszowi.

Tworzenie najlepszego User Story – podsumowanie

INVEST to akronim opisujący dobrze napisaną historię użytkownika. Powinno być:

  1. Niezależny od innych historii użytkownika. Aby można było go modyfikować lub usuwać z Backlogu produktu, jeśli zajdzie taka potrzeba.
  2. Do negocjacji. Powinna określać, co robić, pozostawiając wybór deweloperom.
  3. Wartościowe , tj. uzasadniające biznesowy sens modyfikacji Produktu. Lub Vertical, czyli prezentujący nową cechę Produktu widoczną dla Użytkownika.
  4. Estimable , co oznacza posiadanie definiowalnego kryterium rozmiaru i ukończenia.
  5. Wystarczająco mały , aby można go było ukończyć w jednym sprincie.
  6. Testowalny , aby można było z całą pewnością stwierdzić, że został zaimplementowany.

Jeśli podobają Ci się nasze treści, dołącz do naszej pracowitej społeczności pszczół na Facebooku, Twitterze, LinkedIn, Instagramie, YouTube, Pintereście.

Scrum Guide | 20. INVEST - Creating the best User Story caroline becker avatar 1background

Autor: Caroline Becker

Jako Project Manager Caroline jest ekspertem w znajdowaniu nowych metod projektowania najlepszych przepływów pracy i optymalizacji procesów. Jej zdolności organizacyjne i umiejętność pracy pod presją czasu sprawiają, że jest najlepszą osobą do realizacji skomplikowanych projektów.

Zobacz wszystkie posty

Przewodnik po Scrumie:

  1. Słowniczek podstawowych pojęć, ról i pojęć
  2. Co to jest Scrum?
  3. Wartości Scrum
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Zespół Scrumowy - co to jest i jak działa?
  6. Kim jest Product Owner?
  7. Najczęstsze błędy Product Ownera
  8. Kim jest Scrum Master?
  9. Charakterystyka dobrego Scrum Mastera
  10. Najczęstsze błędy Scrum Mastera
  11. Jakie statystyki i metryki powinien śledzić Scrum Master?
  12. Współpraca Product Ownera ze Scrum Masterem
  13. Zespół Deweloperski w Scrum
  14. Najczęstsze błędy programistów
  15. Artefakty Scrum
  16. Skalowanie Scrum
  17. Backlog Sprintu
  18. Czym jest Backlog Produktu?
  19. Czym są historie użytkowników?
  20. Tworzenie najlepszej historii użytkownika z INVEST
  21. Najczęstsze błędy User Story
  22. Kryteria akceptacji historii użytkownika
  23. Szacowanie i punkty fabularne w Scrumie
  24. Poker Planowania
  25. Drużynowa gra szacowania
  26. Definiowanie przyrostu
  27. Wydarzenia scrumowe
  28. Czym jest Sprint w Scrumie?
  29. Zobowiązania zespołu Scrum – cel produktu, cel sprintu i definicja ukończenia
  30. Co to jest wykres spalania?
  31. Jak stworzyć i zinterpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Velocity in Scrum - Szybkość Zespołu Deweloperskiego
  35. Codzienny Scrum
  36. Planowanie sprintu
  37. Przegląd sprintu
  38. Czym jest retrospektywa sprintu?
  39. Typowe błędy podczas Retrospektywy Sprintu
  40. Pielęgnacja Backlogu Produktu