1 Gli utenti vengono prima di tutto

Come suggerisce il nome, una storia utente descrive come un cliente o un utente impiega il prodotto; è detto dal punto di vista dell’utente. Inoltre, le user story sono particolarmente utili per acquisire una funzionalità specifica, ad esempio la ricerca di un prodotto o la prenotazione. L’immagine seguente illustra la relazione tra l’utente, la storia e la funzionalità del prodotto (simboleggiata dal cerchio).,

Se non sai chi sono gli utenti e i clienti e perché vorrebbero utilizzare il prodotto, non dovresti scrivere storie utente. Effettuare prima la ricerca degli utenti necessaria, ad esempio osservando e intervistando gli utenti. Altrimenti, si corre il rischio di scrivere storie speculative basate su credenze e idee, ma non su dati e prove empiriche.

2 Usa Personas per scoprire le storie giuste

Una grande tecnica per catturare le tue intuizioni sugli utenti e sui clienti sta lavorando con personas., I personaggi sono personaggi immaginari che si basano sulla conoscenza di prima mano del gruppo target. Di solito consistono in un nome e un’immagine; caratteristiche rilevanti, comportamenti e atteggiamenti; e un obiettivo. L’obiettivo è il beneficio che la persona vuole raggiungere o il problema che il personaggio vuole vedere risolto utilizzando il prodotto.

Ma c’è di più: gli obiettivi di persona ti aiutano a scoprire le storie giuste: Chiediti quale funzionalità dovrebbe fornire il prodotto per soddisfare gli obiettivi dei personaggi, come spiego nel mio post Da Personas a User Stories., È possibile scaricare un modello a portata di mano per descrivere i tuoi personaggi da romanpichler.com/tools/persona-template.

3 Crea storie in modo collaborativo

Le storie degli utenti sono intese come una tecnica leggera che ti permette di muoverti velocemente. Non sono una specifica, ma uno strumento di collaborazione. Le storie non dovrebbero mai essere consegnate a un team di sviluppo. Invece, dovrebbero essere incorporati in una conversazione: il proprietario del prodotto e il team dovrebbero discutere le storie insieme. Ciò consente di acquisire solo la quantità minima di informazioni, ridurre il sovraccarico e accelerare la consegna.,

Si può prendere questo approccio ulteriormente e scrivere storie in modo collaborativo come parte del processo di grooming product backlog. Questo sfrutta la creatività e la conoscenza del team e si traduce in storie di utenti migliori.

Se non è possibile coinvolgere il team di sviluppo nel lavoro della storia utente, è necessario considerare l’utilizzo di un’altra tecnica più formale per acquisire le funzionalità del prodotto, ad esempio i casi d’uso.

4 Mantieni le tue storie semplici e concise

Scrivi le tue storie in modo che siano facili da capire. Tenerli semplice e conciso., Evita termini confusi e ambigui e usa la voce attiva. Concentrarsi su ciò che è importante, e lasciare fuori il resto. Il modello qui sotto mette l’utente o il cliente modellato come una persona nella storia e rende esplicito il suo beneficio. Si basa sul modello popolare di Rachel Davies, ma ho sostituito il ruolo utente con il nome della persona per collegare la storia con la persona pertinente.

As < persona>,
Voglio <cosa?>
in modo che < perché?>.,

Usa il modello quando è utile, ma non sentirti obbligato ad applicarlo sempre. Sperimenta diversi modi per scrivere le tue storie per capire cosa funziona meglio per te e il tuo team.

5 Inizia con Epopee

Un’epopea è una storia grande, abbozzata e a grana grossa. In genere è suddiviso in diverse storie utente nel tempo, sfruttando il feedback degli utenti sui primi prototipi e incrementi di prodotto. Si può pensare ad esso come un titolo e un segnaposto per storie più dettagliate.

Iniziare con epics consente di disegnare la funzionalità del prodotto senza impegnarsi nei dettagli., Ciò è particolarmente utile per descrivere nuovi prodotti e funzionalità: ti consente di acquisire l’ambito approssimativo e ti fa guadagnare tempo per saperne di più su come affrontare al meglio le esigenze degli utenti.

Riduce anche il tempo e lo sforzo necessari per integrare nuove intuizioni. Se si dispone di molte storie dettagliate nel product backlog, è spesso complicato e dispendioso in termini di tempo correlare il feedback agli elementi appropriati e comporta il rischio di introdurre incongruenze.,

6 Affina le storie fino a quando non sono pronte

Spezza le tue epopee in storie più piccole e dettagliate fino a quando non sono pronte: chiare, fattibili e testabili. Tutti i membri del team di sviluppo dovrebbero avere una comprensione condivisa del significato della storia; la storia non dovrebbe essere troppo grande e adattarsi comodamente a uno sprint; e ci deve essere un modo efficace per determinare se la storia è fatta.

7 Aggiungi criteri di accettazione

Mentre suddividi le epopee in storie più piccole, ricorda di aggiungere criteri di accettazione., I criteri di accettazione completano la narrazione: ti permettono di descrivere le condizioni che devono essere soddisfatte in modo che la storia sia fatta. I criteri arricchiscono la storia, la rendono testabile e assicurano che la storia possa essere demoed o rilasciata agli utenti e alle altre parti interessate. Come regola generale, mi piace usare da tre a cinque criteri di accettazione per storie dettagliate.

8 Utilizzare carte di carta

Storie utente emerse in Extreme Programming (XP), e la letteratura XP primi parla di carte storia piuttosto che storie utente., C’è una semplice ragione: le storie degli utenti sono state catturate su carte di carta. Questo approccio offre tre vantaggi: in primo luogo, le carte di carta sono economiche e facili da usare. In secondo luogo, facilitano la collaborazione: ognuno può prendere una carta e annotare un’idea. In terzo luogo, le carte possono essere facilmente raggruppate sul tavolo o sul muro per verificare la coerenza e la completezza e per visualizzare le dipendenze. Anche se le tue storie sono memorizzate elettronicamente, vale la pena usare le carte di carta quando scrivi nuove storie.

9 Mantieni le tue storie visibili e accessibili

Le storie vogliono comunicare informazioni., Pertanto non nasconderli su un’unità di rete, nella giungla intranet aziendale o in uno strumento con licenza. Rendili visibili, ad esempio, mettendoli sul muro. Questo favorisce la collaborazione, crea trasparenza, e rende evidente quando si aggiungono troppe storie troppo in fretta, come si inizierà a corto di spazio muro. Uno strumento utile per scoprire, visualizzare e gestire le tue storie è my Product Canvas mostrato di seguito.

10 Non si basano esclusivamente su storie utente

La creazione di una grande esperienza utente (UX) richiede più di storie utente., Le storie degli utenti sono utili per acquisire le funzionalità del prodotto, ma non sono adatte per descrivere i percorsi degli utenti e il design visivo. Pertanto, integra le storie degli utenti con altre tecniche, ad esempio mappe di storie, diagrammi del flusso di lavoro, storyboard, schizzi e modelli.

Inoltre, le storie degli utenti non sono buone per acquisire i requisiti tecnici. Se hai bisogno di comunicare cosa dovrebbe fare un elemento architettonico come un componente o un servizio, scrivi storie tecniche o—che è la mia preferenza—usa un linguaggio di modellazione come UML.,

Infine, scrivere storie utente è utile quando si sviluppa un software che rischia di essere riutilizzato. Ma se si desidera creare rapidamente un prototipo usa e getta o mockup per convalidare un’idea, quindi scrivere storie potrebbe non essere necessario. Ricorda: le storie degli utenti non riguardano la documentazione dei requisiti; vogliono consentirti di muoverti velocemente e sviluppare software il più rapidamente possibile, senza imporre alcun sovraccarico.