Nykyaikaisten kehitysprosessien ydin on ketterä kehitys . Tämä kehittämismenetelmä korostaa pienten, purevien kokoisten käyttäjäkertomusten käyttöä sen määrittelemiseksi, mitä järjestelmä tekee käyttäjän näkökulmasta, ei teknisestä näkökulmasta. Käyttäjä välittää siitä, onko tuote nopea, helppokäyttöinen ja ratkaisee ongelmansa. He eivät välitä, noudattaako se 3-tasoista arkkitehtuuria, onko siinä Mongo DB tai jos se käyttää Railsia tai Asp.netia.
Storyboard That tarjoaa ihanteellisen alustan ketterien käyttäjätarinoiden luomiseen ja keskustelun herättämiseen muodossa, joka on paljon vähemmän verovapaa kuin tekstimuuri.
Käyttäjien tarinoiden yhteydessä "eepos" on yksinkertaisesti hyvin laaja tarina, joka jaetaan myöhemmin moniin erityisiin käyttäjäkertomuksiin. Eeppisestä aloituksesta jokainen saa yhden korkean tason vision. Eeppinen tarina ankkuroi projektin ylhäältä alas, ja jos eepoksen rakentaminen ei ole järkevää, tukiteos on myös vaivannäköä.
Tässä tarinassa on hyvin selvää, mikä on pitkän aikavälin visio ja miltä menestyksen pitäisi näyttää. Hyvän eeppisen tarinan tulisi sisältää:
Erityisesti ohjelmistoja suunniteltaessa on tärkeää saada hyvä visio siitä, millaisia käyttäjät ovat. Kaikki käyttäjät eivät vastaa tätä näkemystä tarkasti, ja käyttäjäryhmiä voi olla useita, mutta nämä erilliset visiot tarvitsevat artikulointia. Käyttäjien ajatteleminen suojaa ensin liialliselta suunnittelulta ja liiallisilta komplikaatioilta, estää uutta tuotetta tarjoamasta jokaiselle jotakin ja hyödyllistä kenellekään.
Kun eepos on luotu ja käyttäjät määritelty, voidaan rakentaa pienempiä, tarkempia tarinoita tietyistä käyttäjäkokemuksista. Alla olevat tarinat jakavat edellä kuvatut kahteen kertomukseen: tilauksen etsiminen ja tuotteen uudelleen tilaaminen.
Nämä kertomukset eivät sisällä teknisiä tietoja; käyttäjät eivät välitä siitä, miten tulokset saavutetaan, niin kauan kuin se suorittaa halutut tehtävät. Samoin UX on kuvattu yleisesti, jotta vältetään innovoinnin tukahduttaminen tai polun pakottaminen. Yleensä tarinoiden pitäisi olla:
Näiden tarinoiden pitäisi herättää keskustelua ja kysymyksiä, kuten:
On täysin järkevää luoda monia tarinoita; itse asiassa sitä pitäisi kannustaa. Joitakin näistä tarinoista ei koskaan käytetä, mutta on tärkeää nähdä polku, jonka he asettivat. Tämä tarinakokoelma poistaa lisävaatimukset ja vaikuttaa testaukseen.
Tarinoiden pitäisi herättää keskustelua siitä, miten ohjelmistoa testataan ja mitkä liiketoimintasäännöt on määriteltävä nimenomaisesti. Esimerkiksi: