User stories eksponują tę pracę do wykonania, która ma dawać business value dla sponsora. Zauważyłem że, zespołom, które posługują się US brakuje czasem szerszego kontekstu dookoła historyjek. Mam tu na myśli rzeczy takie jak:

  • wymagania niefunkcjonalne - są dopisywane gdzieś na boku US, spisywane w SRSach albo są w głowach
  • to, że nie wszystkie "wymagania" przekładają się na konkretne funkcjonalności
  • epiki mogą dotyczyć rzeczy przekrojowych przez funkcjonalności (btw: dobra definicja epika "Since an epic becomes an epic if the team can’t commit to it")
  • to, że wymagania mogą pochodzić z różnych źródeł i świadomość istnienia wszystkich interesariuszy wnosi lepsze zrozumienie pracy

Dla w/w rzeczy jakby nie było miejsca w backlogu, więc plątają się to tu to tam i każdy ma własny pomysł na ich przechowywanie. Brak jednolitego sposobu na przechowywanie wszystkich wymagań utrudnia ich komunikowanie, a zespołowi utrudnia złapanie szerszego kontekstu tego, co ma do zrobienia.

Format historyjki świetnie nadaje się do spisanie wszystkich punktów widzenia na tworzony produkt. Poniżej przykłady:
  • Jako Klient chcę zamówić szkolenie, aby wziąć w nim udział
  • Jako Zarząd chcemy dowiadywać się, jaki jest aktualny obrót, aby mieć informacje o aktualnych przychodach z portalu
  • Jako Architekt chcę, aby system S czerpał informacje o klientach z naszego systemu V nadzorującego procesy biznesowe
  • Jako Zespół chcemy pozbyć się ORMa, bo do tego typu projektu kompletnie się nie nadaje i spowalnia naszą pracę
  • Jako Grafik, chcę aby używano Velocity zamiast JSP, abym mógł szybciej przygotowywać widoki

Jasne, że nie wszystkie wymienione historyjki idą na tablicę. Przynajmniej nie w pierwotnej postaci. Przede wszystkim:
  • Zespołowi dają szerszy ogląd projektu
  • Nie uciekają historyjki techniczne; niby powinny być podczepione pod US, ale zauważyłem, że jak coś nie jest wprost nazwane, to lubi się zagubić w mrokach niepamięci

Po za w/w wspomaganie się hisotryjową strukturą (Jako X, chcę Y, aby Z, bardzo pomaga w zbieraniu wymagań. Zazwyczaj jeśli, ktoś nie potrafi sformułować Z, czyli konkretnego powodu powiązanego z projektem, to sam z wymagania rezygnuje, bez większej przykrości.

.