Najczęściej popełniane błędy podczas pisania user stories

Dzisiaj każdy zespół chce przejść na zwinne metodyki programowania typu Agile, czyli umieścić użytkownika w centrum planowania procesu podczas budowania produktu. W końcu budujemy produkt dla użytkowników końcowych, prawda? User stories (historie użytkowników) są jednym z podstawowych narzędzi, które pomagają zespołom pamiętać o użytkowniku podczas definiowania produktu oraz jego funkcjonalności. Dużo mówi się o tym, jak je poprawnie pisać.

Pisząc user stories, wydaje nam się niejednokrotnie, że piszemy je z perspektywy użytkownika. Jednak ostatecznie zawsze są one wypaczone przez naszą stronniczość oraz specjalistyczną wiedzę. Często błędy te są ze sobą połączone i nigdy nie kończą się wyłącznie na jednym nietrafnym osądzie. Dlatego chcę omówić niektóre z typowych i najczęściej popełnianych błędów przez zespoły podczas pisania user stories.

1. User stories, które są zbyt szerokie, ogólne

Gdy historie użytkowników są zbyt ogólne, łatwo pominąć kluczowe informacje dotyczące oczekiwanego działania i potrzeby. Jeśli w user stories istnieje wiele „i” bądź „lub” jest to wskazówka, że są one zbyt szerokie i należy rozważyć rozpisanie ich ponownie. Istnieje również bardzo dużo szansa, że szeroko napisana user story jest naprawdę epicka, ale... No właśnie.

2. User stories, które są zbyt dobre

Gdy user stories są zbyt dobrze napisane, zaczynamy mówić o tym, jak zamierzamy je wdrożyć. Usuwa to skupienie użytkownika oraz prowadzi do słabej komunikacji w zespole.

3. Brak możliwości negocjacji

User stories nie powinny być konkretnym i dokładnym opisem funkcji. Czasami historia użytkownika została napisana w tak charakterystyczny sposób, że zespół ma trudności, aby poprawnie ją wdrożyć, ponieważ istnieje łatwiejsza alternatywa. W takich przypadkach zespół powinien być skłonny do kompromisu w kwestii samego podejścia, pod warunkiem, że nie zaszkodzi to wartości, jaką ma z niej czerpać użytkownik.

4. Powtórzenie user story w kryteriach akceptacji

Kryteria akceptacji pozwalają na opisanie warunków, które należy spełnić, aby story zostało oznaczone jako ukończone. Zapewnia to zbieranie opinii, pomoc w planowaniu pracy zespołu oraz śledzenie ich pracy. Dzięki temu user story jest bardziej bogate, precyzyjne oraz testowalne.

5. Posiadanie niezdefiniowanego użytkownika

Wspominanie o osobowości użytkownika w każdej user story może wydawać się niepoważne. Jednak z drugiej strony może przynieść ogromną wartość pod względem wyniku. Jest to szczególnie ważne, jeżeli Twój produkt ma więcej niż jednego użytkownika. Oczywiście będą dostępne funkcje dopasowane do różnych postaci. Jeśli chcesz, aby Twój zespół był bardziej dopasowany do wyników, których od niego oczekujesz, musi wiedzieć, kim są użytkownicy końcowi oraz jakie korzyści uzyskają dzięki wprowadzeniu danej funkcjonalności.

6. Zły kontekst

Po pewnym czasie prawie każda user story zaczyna wyglądać tak samo np. jako menedżer treści chcę edytor tekstu, aby móc edytować treść. Wszystko to mówi zespołowi, że chcesz, aby zbudowali edytor tekstu i nic więcej. Jeżeli od dłuższego czasu zapisujesz kilka user stories, zrób sobie przerwę i wróć do nich z nową perspektywą. Czasami nawet po przerwie, możesz nie być w stanie wymyślić czegoś bardziej znaczącego. To dobry wskaźnik mówiący, że powinieneś więcej rozmawiać z użytkownikami i lepiej rozumieć ich potrzeby. Naprawdę nie ma potrzeby wymyślać koła od nowa.

Wniosek

Chociaż użycie szablonu user stories może być przydatne, nigdy nie jest tak proste, jak się wydaje. Jeden błąd podczas pisania często prowadzi do szeregu innych jako produktów ubocznych. A wtedy znajdziemy się w jeszcze większym bałaganie niż gdybyśmy w ogóle go nie pisali. Dlatego jeśli decydujemy się na jego przygotowanie, poświęćmy temu naprawdę dużo czasu i uwagi.