Podstawową zasadą nowoczesnych procesów programistycznych jest zwinny rozwój . Ta metodologia rozwoju kładzie nacisk na używanie małych, niewielkich historyjek użytkownika w celu zdefiniowania, co system robi z perspektywy użytkownika, a nie technicznej. Użytkownikowi zależy na tym, czy produkt jest szybki, łatwy w użyciu i rozwiązuje jego problem. Nie obchodzi ich, czy jest zgodny z architekturą trójwarstwową, ma Mongo DB, czy używa Railsów lub Asp.net.
Storyboard That stanowi idealną platformę do tworzenia zwinnych historii użytkowników i inicjowania rozmów w formacie, który jest znacznie mniej obciążający niż ściana tekstu.
W kontekście historyjek użytkownika „epos” to po prostu bardzo obszerna historia, która zostanie później podzielona na wiele konkretnych historyjek użytkownika. Rozpoczęcie od epopei łączy wszystkich z jedną wizją na wysokim poziomie. Epicka historia zakotwicza projekt od góry do dołu, a jeśli konstruowanie epickiego nie ma sensu, wspieranie pracy również będzie stratą wysiłku.
W tej historii jest bardzo jasne, jaka jest długoterminowa wizja i jak powinien wyglądać sukces. Dobra epicka historia powinna zawierać:
Szczególnie przy projektowaniu oprogramowania ważne jest, aby mieć dobrą wizję tego, jacy będą użytkownicy. Nie każdy użytkownik dokładnie dopasuje się do tej wizji i może istnieć wiele kategorii użytkowników, ale te dyskretne wizje wymagają artykulacji. Myślenie o użytkownikach przede wszystkim chroni przed nadmierną inżynierią i komplikacjami, uniemożliwiając nowemu produktowi coś dla wszystkich i nieprzydatność nikomu.
Po utworzeniu epopei i zdefiniowaniu użytkowników można tworzyć mniejsze, bardziej szczegółowe historie dotyczące konkretnych doświadczeń użytkowników. Poniższe historie dzielą opisane powyżej na dwie narracje: wyszukiwanie zamówienia i ponowne zamawianie produktu.
Te narracje nie zawierają informacji technicznych; użytkownicy nie dbają o to, jak osiągane są wyniki, o ile wykonuje pożądane zadania. Podobnie UX jest przedstawiany ogólnie, aby uniknąć tłumienia innowacji lub forsowania ścieżki. Ogólnie rzecz biorąc, historie powinny być:
Te historie powinny zachęcać do rozmowy i pytań, takich jak:
Całkowicie rozsądne jest tworzenie wielu historii; w rzeczywistości należy do tego zachęcać. Niektóre z tych historii nigdy nie zostaną wykorzystane, ale ważne jest, aby zobaczyć ścieżkę, którą wyznaczyły. Ten zbiór historii wyeliminuje dodatkowe wymagania i wpłynie na testowanie.
Historie powinny prowokować i skłaniać do dyskusji o tym, jak oprogramowanie będzie testowane i jakie reguły biznesowe należy wyraźnie zdefiniować. Na przykład: