Laboratorium Scruma: User Stories

book

Wiedza | PROCES

User Stories to jedno z najczęściej wykorzystywanych a zarazem niezrozumianych narzędzi w procesie wytwarzania oprogramowania. Warto przyjrzeć się im z bliska oraz zapytać o możliwości i ograniczenia. Oraz najczęściej popełniane błędy...

Cześć Beatko,

Potrzebuję Twojej pomocy!!!

Mamy mały problem z opisami user story tworzonymi przez naszych Product Ownerów. A raczej ich brakiem. Myślę, że brak ten wynika z niewiedzy, co powinno być zawarte w takim wpisie.

Masz może jakiś przystępny artykuł na ten temat, który by nam pomógł? Bądź może posiadasz przykład dobrze opisanego user story, na podstawie którego moglibyśmy wypracować własny szablon?

Będę wdzięczna za pomoc.

 

Moja odpowiedź

Cześć Kasiu,

Przede wszystkim zastanówcie się, czy używanie User Stories jest w waszym przypadku potrzebne. Scrum ich nie narzuca, jest to jedno z wielu narzędzi, które można użyć do opisania wymagań biznesowych, może inne sprawdzi się u Was lepiej.

User stories są obietnicą rozmowy

Alistair Cockburn powiedział kiedyś że “User story jest obietnicą rozmowy” (ang. “A user story is a promise for a conversation”) i to jest najważniejsze w kontakcie między PO a zespołem deweloperskim.

Zastanów się czy dostatecznie dużo czasu poświęcacie na omówienie wymagań i upewnienie się, że obie strony je rozumieją.

To co ląduje w Backlogu Produktu ma być czytelnym przypomnieniem tego, na co się zgodziliśmy rozmawiając twarzą w twarz.

Polecam techniki:

  • User Story Mapping
  • Event Storming

 

User Story to jedno z wielu narzędzi, które ma na celu przybliżenie całemu zespołowi pracującemu nad produktem, jaki jest cel biznesowy zadania. Jeżeli od jakiegoś czasu cel nie jest jasny, usiądźcie razem i porozmawiajcie o tym, co jest potrzebne dla każdej ze stron. Stwórzcie szablon elementu Backlogu Produktu, który spełnia Wasze potrzeby i spróbujcie go używać.

 

Nie używaj User Stories jako tytułu historyjki

To zwyczajnie zaciemnia obraz sytuacji. User Stories jakie widziałam u klientów:

 

Przykład 1:

Jako Produkt Owner chcę, aby powstała funkcjonalność nanoszenia… (tutaj ucięła Jira)

Jako Produkt Owner chcę, aby pojawiła się nowa funkcjonalność…

 

I tak dalej, co wiecie po zobaczeniu tych tytułów?

 

Przykład 2:

Jako baza danych chcę zaciągnąć informację o nowych…

Jako strona internetowa chcę wyświetlić listę dostępnych…

 

I tak dalej, tutaj nie dość że nic nie wiadomo o tym co ma być zrobione, to jeszcze widać wyraźnie że, elementy Backlogu nie dostarczają wartości biznesowej.

 

User Story to historia użytkownika, nie bazy danych, Właściciela Produktu czy nawet sponsora projektu. Chodzi w nich o pokazanie perspektywy tych, którzy mają tego używać. Bez spełnienia ich potrzeb, nie będzie dobrego produktu.

 

Oto kilka wartościowych materiałów na temat User Story:

 

A co do elementów Backlogu Produktu ogólnie. Tytuł historyjki, powinien jak najzwięźlej opisać o który element Backlogu Produktu nam chodzi.

 

Przykład 3:

Dodać funkcjonalność stopki do edytora tekstu.

Wstawianie zdjęć na postach.

 

Te tytuły nie mówią nic o tym dla kogo ani po co, ale za to jedno zerknięcie na Backlog Produktu i wiemy gdzie jest element którego szukaliśmy, możemy na niego kliknąć i dowiedzieć się więcej.

 

To treść elementu Backloga Produktu ma zawierać dla kogo to ma być i po co to robimy. Wiele zespołów korzysta z warunków akceptacji, dzięki którym wiedzą dokładnie jakie warunki musi spełniać PBI aby uznać go za skończony. Fajne są też testy BDD, nawet jeżeli nie implementujemy ich wprost, jasno wyrażają jak dokładnie funkcjonalność ma działać. Z drugiej strony techniki takie, mogą ograniczać zespołowi dobranie metod w czasie pracy nad historyjką, dlatego nie dla każdego zespołu są dobre.

 

Co można zawrzeć w elementach Backlogu Produktu:

  • dla kogo, czyli dla której grupy użytkowników naszej aplikacji
  • dlaczego, jaki jest biznesowy powód stoi za tym, że właśnie tą funkcjonalność chcemy zrobić
  • warunki ukończenia czy to w formie warunków akceptacji czy testów BDD

 

Najfajniej jeżeli te elementu są zawsze ułożone w tej samej kolejności, abyśmy mogli się do niej przyzwyczaić.

 

Przykład

 

Działanie:

Dodać możliwość wstawiania standardowych emotikonek w komentarz

 

Dlaczego:

Prośba o dodanie emotikonek w komentarzach pojawiła się 879 razy w feedbacku od naszych użytkowników.

 

Dla kogo:

Kupujący

 

Warunki akceptacji:

 

  • Po wpisaniu jednej ze standardowych buziek (dostępne w załączniku) w komentarzu oraz kliknięciu enter, buźka automatycznie zamieni się na obrazek (dostępne w załączniku)  

 

 

Powiązane artykuły, mogą Cię też zainteresować!

Definition of Done dla Product Ownerów - Poradnik Użytkownika

Pewnie słyszeliście już nie raz o Definition of Done. DoD jest ważne i potrzebne. Tylko do czego służyProduct Ownerowi...

Po co nam dobry Product Backlog?

W Scrumie za jakość odpowiada zespół deweloperski. Zespół. Nie manager. Nie Produkt Owner. Nie Scrum Master.Zespół dewel...

Czy Twój zespół na pewno jest interdyscyplinarny? - Część 1

Jeśli wypowiem słowo “zespół” bez żadnego kontekstu, to prawdopodobnie większość zapytanych pomyśli o zespole muzycznym....

Ilustrowany Scrum Guide - darmowy e-book do ściągnięcia

Scrum: jest lekki, łatwy do zrozumienia i trudny w implementacji. Dlatego 7 listopada 2017 Jeff Sutherland i Ken Schwab...