Utente generico: questo è l’errore più grosso e dannoso in cui si può incappare quando si generano le user story. Considerare un utente troppo generico porta inevitabilmente a due problemi che rallentano il rilascio del sotware. Primo: le necessità dell’utente sono talmente tante che ci si perderebbe ipotizzando tutte le features realizzabili. Secondo: non si potrebbe raggiungere il livello di dettaglio sperato per l’implementazione. Quando si realizza una user story è bene avere in mente uno specifico utente. Quest’utente ha solo un limitato numero di requisiti e può rispondere in modo dettagliato a delle domande.

Utenti poco conosciuti / scenario non familiare: il design del software dà i risultati migliori quando si progetta software per sè stessi. Le user story sono facili da ottenere e molto accurate. Una buona fetta di software ben progettati è realizzata da chi lo fa per i propri bisogni. Quando invece ci si trova a creare software per user story che non si conoscono e per scenari/domini non conosciuti le cose si complicano. Intervistare gli utenti è il primo passo per raccogliere informazioni, sicuramente qualcosa verrà dimenticato e solo i primi test con il prototipo dell’applicazione potranno segnalare questi problemi. Due suggerimenti: il primo è quello di impersonare l’utente seguendo l’intero processo in prima persona, il secondo è quello di dividere gli utenti in modo da individuare quelli che analizzeranno le prime versioni del software (alpha e beta). I feedback ricevuti in questa fase daranno informazioni più importanti di quelle raccolte dalle interviste.

Feature specifiche o non-user feature: quando si lavora a feature che gli utenti non vedono il concetto di user story viene un po’ meno, si pensi per esempio ad architettura, amministrazione etc…basta ricordare due cose per rendere le user story più concrete. In primo luogo gli amministratori di sistema e gli sviluppatori sono anch’essi degli utenti. Secondo: realizzare ciò “che sta sotto”, parlando di infrastruttura, più tardi possibile in modo da rispondere prontamente agli utenti e risparmiando tempo prezioso nel caso in cui ci si accorgesse che l’infrastruttura pensata non corrisponde alle reali esigenze.

Storie testuali: è molto facile dilungarsi in diagrammi e descrizioni che alla fine sono difficili da leggere e per l’utente anche difficili da comprendere. La miglior soluzione è quella di realizzare immagini e storyboard al posto del testo. Una storyboard è una specie di flow chart in cui l’utente vede le componenti in gioco, schermate del sistema che userà e link che rappresentano le transizioni tra una schermate ed un’altra. In questo modo si può evitare di dover scrivere la maggior parte del testo e dei commenti posticipando il tutto ad un secondo momento.

Consiglio la lettura di Do’s and Don’ts for User Stories, Use Cases, Scenarios.