Jak pisać dobre historie użytkownika w Scrumie

W przybliżeniu 70% projektów technologicznych kończy się niepowodzeniem. Przez dekady powszechnie uważano, że projekty kończą się niepowodzeniem, ponieważ nie stosują najlepszych praktyk lub zespół nie posiada wszystkich niezbędnych umiejętności. Jednak w ostatnich dekadach zauważalnie poprawiła się stosowanie najlepszych praktyk, umiejętności i kompetencji — dlaczego więc projekty dalej kończą się niepowodzeniem?

Biorąc pod uwagę, że 70% projektów oprogramowania kończy się niepowodzeniem z powodu słabej specyfikacji wymagań. Szacunkowe koszty ponownej pracy związane z tymi niepowodzeniami przekraczają 45 miliardów dolarów rocznie.

Pytanie brzmi — dlaczego to się dzieje? Odpowiedź ma dwa aspekty. Po pierwsze, wymagania biznesowe często tracą skupienie na kliencie; po drugie, brakuje im ogólnego ramowego punktu odniesienia, który pozwala analitykom wymagań prowadzić i śledzić wymagania od potrzeb klientów i strategii po rozwiązanie, które jest wdrażane.

Aby pisać dobre wymagania lub historie użytkownika, postępuj zgodnie z tymi krokami:

1. Zdefiniuj jak najwięcej personów, aby reprezentować użytkowników systemu.To pomoże Ci skupić się na kliencie i prowadzić oraz śledzić wymagania na podstawie potrzeb klientów. Wprowadził je Alan Cooper — persona to definicja archetypowych użytkowników systemu — przykłady osób, które z nim interakcjonują. Użytkownicy nie muszą być ani reprezentować konkretnych osób. Użytkownikiem może być również organizacja.
2. Upewnij się, że Twoje historie użytkownika spełniają zasady „3C”:

• Karta — Powinna być zapisana na karcie katalogowej lub kartce kolorowej
• Rozmowa — Uzyskaj szczegółowe informacje od właściciela produktu
• Potwierdzenie — Upewnij się, że została poprawnie zaimplementowana. Musi spełniać kryteria akceptacji użytkownika.

3. Podziel historie użytkownika na odpowiednio małe fragmenty, aby mieściły się w jednym Sprintie. Niektóre sposoby podziału historii to:

• Podział według kroków procesu
• Podział według kanałów wejściowych/wyjściowych
• Podział według opcji użytkownika
• Podział według personów/rol
• Podział według zakresu danych

4. Upewnij się, że każda historia użytkownika spełnia zasady mnemotechniczne INVEST:

Agilemnemonik INVEST, stworzony przez Billa Wake’a, służy jako przewodnik zapewniający wysoką jakość elementów listy produktu (PBIs), zazwyczaj zapisanych w formacie historii użytkownika.

• Niezależne: Historie powinny być jak najbardziej niezależne.
• Negocjowalne: Historia nie jest kontraktem. Historia to zaproszenie do rozmowy. Historia uchwyca istotę tego, co jest pożądane.
• Wartościowe: Jeśli historia nie ma oczywistej wartości, nie powinna być wykonywana.
• Oszacowalny: Historia musi być oszacowalna lub zdefiniowana pod kątem rozmiaru, aby mogła być odpowiednio priorytetyzowana.
• Mały: W iteracji trwającej dwa tygodnie, historie użytkownika powinny wynosić średnio 3–4 dni pracy — łącznie! Obejmuje to całą pracę wymaganą do osiągnięcia stanu „Gotowe”.Im mniejsza historia użytkownika, tym wyższa dokładność oszacowania!
• Testowalny: Każda historia musi być testowalna, aby mogła być uznana za „Gotową”.

• Pisanie celów SMART i kryteriów INVEST dla historii użytkownika
• Temat vs Epicka historia vs historia użytkownika vs zadanie
• Co to jest DEEP w Backlogu Produktu?
• Jak napisać wizję produktu dla projektu Scrum?
• Jak używać tablicy Scrum do rozwoju agilnego?
• Kto tworzy elementy Backlogu Produktu lub historie użytkownika w Scrumie?
• Co to jest oszacowanie agilne?
• Co to jest punkt historii w agilności? Jak oszacować historie użytkownika?
• Dzielenie historii użytkownika – pionowy cięciu vs poziomy cięcie