Przewodnik po Scrumie | 21. Błędy w historii użytkownika

Historie użytkowników opisują działanie nowej funkcjonalności Produktu w języku codziennym lub biznesowym. Jednak ich przygotowanie wymaga dużo czasu, wysiłku i myślenia. W dzisiejszym wpisie wskazujemy najczęstsze błędy User Story i podpowiadamy, jak sobie z nimi radzić.

Najczęstsze błędy w User Story – spis treści:

1. Wstęp
2. Problemy z 3W
3. Problemy z 3C
4. Błędy w User Story – Podsumowanie

Wstęp

User Story może być świetnym narzędziem motywującym zespół do proponowania nowych rozwiązań problemów przedstawionych z perspektywy użytkownika. O tym, czym jest User Story, pisaliśmy w osobnym wpisie. W tym artykule przedstawiliśmy INVEST, popularną metodę pisania dobrych historii użytkowników. Dzisiaj skupimy się na błędach User Story.

Problemy z 3W

Odpowiednia historia użytkownika odpowiada na pytania:

• Kto? (Kto jest docelowym użytkownikiem Produktu?)
• Co? (Jakie możliwości ma Produkt i co potrafi?)
• Czemu? (Do czego to służy?)

Jednak odpowiedziom na każde z tych pytań mogą towarzyszyć problemy. Najmniej powszechnym problemem jest wątpliwość, co powinno się zmienić w produkcie w odpowiedzi na potrzeby klienta. Dlatego skupimy się na problemach dotyczących Kto? i dlaczego?

Kto – persona użytkownika

Jednym z najczęstszych błędów popełnianych podczas tworzenia User Stories jest niedostateczna odpowiedź na pytanie: dla kogo? Innymi słowy, kim jest użytkownik, dla którego przeznaczona jest planowana zmiana?

Często ogólna odpowiedź wskazująca na Klienta lub Użytkownika końcowego jako odbiorcę zmiany nie wystarcza. Rozwiązaniem tego problemu jest wyobrażenie odbiorcy jako konkretnej osoby. Persona to modelowy wizerunek klienta docelowego. Innymi słowy, persona to reprezentacja osoby, która będzie korzystać z Produktu w określony sposób.

Po przeanalizowaniu Twojego User Story może się okazać, że opowiada on historie różnych osób w tym samym czasie. Jeśli docelowych użytkowników jest wielu, warto rozważyć podzielenie User Story na mniejsze fragmenty , aby uniknąć działań sprzecznych, wykluczających się lub po prostu nieefektywnych.

Czemu? – słabo zdefiniowany cel

Czasami ostatnia sekcja User Story staje się źródłem problemów. Powinna określać wartość biznesową zmian wprowadzonych podczas realizacji User Story. Spójrz na przykład błędów User Story, gdzie opis dodatkowej funkcjonalności zastępuje cel:

Jako klient chcę kupić magiczną różdżkę jednym kliknięciem, ponieważ chcę kupić latający dywan w przyszłym tygodniu.

Zamiast podawać powód zakupu magicznej różdżki, ta historia użytkownika dodaje kolejny przedmiot do listy zakupów potencjalnego klienta. Dlatego przygotowując Historię Użytkownika nie zapominaj o przyczynach zmian funkcjonalności Produktu.

Problemy z 3C

Proces pracy z User Stories możemy podzielić na trzy etapy zwane 3C:

• Karta – Karta, na której zapisana jest Historia Użytkownika
• Rozmowa – Rozmowa w Zespole Scrumowym na temat karty User Story
• Potwierdzenie – określenie kryteriów akceptacji potwierdzających wykonanie zadania

W każdym z nich mogą wystąpić błędy, które opisujemy poniżej.

Karta

Karta pamięci, na której przechowywana jest historia użytkownika, ma ograniczoną pojemność. Dlatego najczęstsze problemy dotyczą długości i objętości User Story. User Story potrzebuje spójności i bez owijania w bawełnę, jak mówią, w tak precyzyjnym stopniu, że liczy się każde słowo.

Dzieje się tak, ponieważ problem karty User Story ma dwa wymiary. Jednym z nich jest sposób jego sformułowania: zwięzły i zawierający niezbędną minimalną ilość wyliczeń. Drugi to rzeczywisty rozmiar User Story. Jedno zdanie ogólne może wyrazić ogromną liczbę zadań, których nie da się wykonać podczas jednego Sprintu.

Rozmowa

Jednozdaniowe sformułowanie User Story jest punktem wyjścia do rozmowy z Zespołem Deweloperskim. Dlatego niewłaściwe jest traktowanie go jako opisu zadania do wykonania. Wyłącza możliwość negocjacji i dyskusji na temat różnych sposobów jej realizacji. User Story nie powinien być traktowany jako opis wymagań dla nowej funkcjonalności produktu, jest raczej zaproszeniem do rozmowy na temat konkretnych rozwiązań technicznych, które doprowadzą do realizacji wartości biznesowej zdefiniowanej przez User Story.

Potwierdzenie

O kryteriach akceptacji, które muszą być określone dla każdej User Story, pisaliśmy szczegółowo w tekście opisującym, czym jest User Story. Jednym z powszechnych błędów jest jednak brak niejasności kryteriów wydajności.

Dobrze napisana User Story zawiera opis sytuacji, w której została zaimplementowana. Jego testem jest skorzystanie przez Użytkownika z nowej funkcjonalności stworzonej przez Zespół Deweloperski.

Przydatnym narzędziem do walidacji User Story jest opracowanie testu akceptacyjnego. Zwykle znajduje się po drugiej stronie karty zawierającej Historię użytkownika.

Błędy w User Story – Podsumowanie

Przygotowując i aplikując User Stories warto trzymać się następujących zasad:

• Precyzyjnej identyfikacji Użytkownika , którego dotyczy zmiana
• Jasno określ cel budowania nowej funkcjonalności produktu
• Utrzymuj głośność tak krótką, jak to tylko możliwe
• Traktuj User Story jako punkt wyjścia do dyskusji o rozwiązaniach z Zespołem Deweloperskim
• Ustal jasne zasady akceptacji

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.

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