Un principio fondamentale dei moderni processi di sviluppo è lo sviluppo agile . Questa metodologia di sviluppo sottolinea l'utilizzo di storie utente piccole e di dimensioni ridotte per definire cosa fa un sistema dal punto di vista dell'utente, non da quello tecnico. Un utente si preoccupa se un prodotto è veloce, facile da usare e risolve il suo problema. A loro non importa se segue un'architettura a 3 livelli, ha Mongo DB o se utilizza Rails o Asp.net.
Storyboard That fornisce una piattaforma ideale per creare storie utente agili e stimolare la conversazione in un formato molto meno oneroso di un muro di testo.
Nel contesto delle storie utente, un "epopea" è semplicemente una storia molto ampia che verrà successivamente suddivisa in molte storie utente specifiche. Iniziare con un'epopea allinea tutti con un'unica visione di alto livello. La storia epica àncora un progetto dall'alto verso il basso, e se non ha senso costruire un'epopea, anche il lavoro di supporto sarà uno spreco di energie.
In questa storia, è molto chiaro qual è la visione a lungo termine e come dovrebbe essere il successo. Una buona storia epica dovrebbe includere:
Soprattutto quando si progetta un software, è importante avere una buona visione di come saranno gli utenti. Non tutti gli utenti corrisponderanno esattamente a questa visione e potrebbero esserci più categorie di utenti, ma queste visioni discrete richiedono un'articolazione. Pensare agli utenti prima di tutto protegge dall'eccesso di ingegneria e di complicazione, impedendo a un nuovo prodotto di avere qualcosa per tutti e di non essere utile a nessuno.
Una volta stabilita un'epopea e definiti gli utenti, è possibile costruire storie più piccole e specifiche su particolari esperienze utente. Le storie seguenti suddividono quanto descritto sopra in due narrazioni: cercare un ordine e riordinare un prodotto.
Queste narrazioni non contengono informazioni tecniche; agli utenti non interessa come vengono raggiunti i risultati, purché svolga i compiti desiderati. Allo stesso modo, la UX è rappresentata genericamente, per evitare di soffocare l'innovazione o forzare un percorso. In generale, le storie dovrebbero essere:
Queste storie dovrebbero invitare alla conversazione e alle domande, come:
È perfettamente ragionevole creare molte storie; anzi, dovrebbe essere incoraggiato. Alcune di queste storie non verranno mai utilizzate, ma è importante vedere il percorso che hanno tracciato. Questa raccolta di storie eliminerà requisiti aggiuntivi e influenzerà i test.
Le storie dovrebbero provocare e informare la discussione su come verrà testato il software e quali regole aziendali devono essere definite in modo esplicito. Per esempio: