En kerne for moderne udviklingsprocesser er agil udvikling . Denne udviklingsmetodik understreger at bruge små, bidstore brugerhistorier til at definere, hvad et system gør ud fra et brugerperspektiv, ikke et teknisk. En bruger er ligeglad med, om et produkt er hurtigt, let at bruge og løser deres problem. De er ligeglade med, om den følger en 3-lags arkitektur, har Mongo DB, eller om den bruger Rails eller Asp.net.
Storyboard That giver en ideel platform til at skabe smidige brugerhistorier og skabe samtale i et format, der er meget mindre belastende end en tekstmur.
I forbindelse med brugerhistorier er en "epos" simpelthen en meget bred historie, der senere vil blive opdelt i mange specifikke brugerhistorier. Starter med en episk tilpasser alle med en enkelt vision på højt niveau. Den episke historie forankrer et projekt oppefra og ned, og hvis det ikke giver mening at konstruere et epos, vil understøttende arbejde også være spild af kræfter.
I denne historie er det meget klart, hvad den langsigtede vision er, og hvordan succes skal se ud. En god episk historie bør omfatte:
Især når man designer software, er det vigtigt at have en god vision om, hvordan brugerne vil se ud. Ikke alle brugere vil matche denne vision præcist, og der kan være flere kategorier af brugere, men disse diskrete visioner har brug for artikulation. At tænke på brugerne beskytter først mod overkonstruktion og overkomplikation, forhindrer et nyt produkt i at have noget for enhver smag og ikke er nyttigt for nogen.
Når først et epos er etableret, og brugerne er defineret, kan der konstrueres mindre, mere specifikke historier om bestemte brugeroplevelser. Historierne nedenfor opdeler ovenstående i to fortællinger: at slå en ordre op og ombestille et produkt.
Disse fortællinger indeholder ikke tekniske oplysninger; brugerne er ligeglade med, hvordan resultaterne opnås, så længe den udfører de ønskede opgaver. På samme måde er UX afbildet generisk for at undgå at kvæle innovation eller tvinge en vej. Generelt skal historier være:
Disse historier bør invitere til samtale og spørgsmål, såsom:
Det er helt rimeligt at skabe mange historier; faktisk bør det opmuntres. Nogle af disse historier vil aldrig blive brugt, men det er vigtigt at se den vej, de satte ned. Denne samling historier vil skylle yderligere krav og påvirke testning.
Historierne skal fremkalde og informere diskussion om, hvordan softwaren vil blive testet, og hvilke forretningsregler, der skal defineres eksplicit. For eksempel: