Come scrivere storie utente migliori con i cetriolini (modello incluso)

Le storie degli utenti sono una tecnica Agile per definire le funzionalità e i requisiti del prodotto. Si concentrano sulla narrazione di un’azione che l’utente compie e sulle aspettative di successo. Il concetto di storie dell’utente è molto diffuso, ma raccontare buone storie può essere piuttosto difficile.

Negli ultimi anni, però, le storie degli utenti sono state un po’ criticate, perché sono leggermente semplificate e mancano di empatia nei confronti dell’utente.

Buone notizie: c’è un modo migliore! Si chiamano cetriolini, ma a differenza dei sottaceti non sono qui per inacidire la vostra vita. (A meno che non siate amanti dei sottaceti, suppongo!) 🥒

TL;DR

Se siete un po’ di fretta, ecco il riassunto (anche se vi incoraggio a continuare a leggere per accedere ai modelli).

• Le storie degli utenti si concentrano sull’utente, non sul prodotto.
• Delineate le vostre personas per aggiungere un contesto.
• Aggiungete l’empatia alle vostre storie per comprendere azioni e motivazioni.
• Cetriolini: un modo migliore di scrivere storie.
• Usate i cetrioli per concentrarvi sui risultati, non solo sulle realizzazioni.

Cosa sono le storie degli utenti?

Le storie degli utenti sono descrizioni brevi e semplici di una soluzione elaborata dal team, raccontate dal punto di vista della persona che sta svolgendo l’interazione. Fanno parte di un’epopea più ampia che descrive il problema effettivo da risolvere e il motivo per cui lo si sta risolvendo.

La parola chiave in questo caso è utente: una storia utente mette al centro l’utente, non il prodotto.

Una storia utente si concentra solitamente su tre aree:

• Come un(chi)
• Voglio(cosa)
• Così che(perché)

Tutto questo è solitamente seguito da criteri di accettazione, che definiscono come sapere se l’interazione ha avuto successo.

Chi: Utilizzo delle personas per delineare le storie degli utenti

Se non avete ancora definito o compreso i vostri utenti, non dovreste scrivere storie di utenti. Iniziate prima di tutto con la scoperta, tracciate un percorso del cliente e create delle personas di utenti rilevanti che vi aiuteranno a definire ulteriormente queste storie.

Una persona può aiutarvi a capire e a fornire un contesto al “chi” della storia dell’utente – in altre parole, chi sta conducendo questa interazione.

Questo è importante perché inevitabilmente ci saranno diversi segmenti di clienti, ruoli e autorizzazioni, quindi è importante definire le interazioni per soddisfare questi diversi tipi di utenti.

Cosa: Interazioni tra storie utente

Il “cosa” di una storia utente si concentra sull’interazione stessa. La cosa difficile è assicurarsi che il “che cosa” si concentri su ciò che l’utente deve fare, piuttosto che su ciò che l’utente vuole fare, e questo è il punto in cui il tipico modello di storia cade un po’ a pezzi.

Per aggiungere un po’ di empatia alla storia stessa, è importante evidenziare come l’utente potrebbe sentirsi quando interagisce con una particolare azione.

Ad esempio, nessuno vuole inserire una password complicata con lettere maiuscole, caratteri speciali e una lunghezza minima, ma sa che dovrebbe farlo. In questo caso, si tratta di qualcosa che l’utente è tenuto a fare.

Perché: il motivo dell’azione della storia utente

La terza parte del modello di storia dell’utente è il “perché”, cioè il motivo per cui l’utente vuole (o deve) compiere una particolare azione.

Tornando all’esempio precedente dell’inserimento delle password:

Come amministratore, sono tenuto a creare una password complicata, in modo che il mio account sia sicuro.

Ora capiamo il chi, il cosa e il perché della storia, ma c’è un problema. Manca ancora l’empatia e il contesto, perché siamo onesti: nessuno vuole che le password complicate siano un requisito, ma tutti vogliamo account sicuri.

Durante i test, il team di QA si limita a verificare se la password è sicura, non se il processo è frustrante per l’utente.

Inserire il modello di storia utente Gherkin

I cetrioli sono un modo per aggiungere alle storie utente e fornire uno scenario completo che aiuterà gli sviluppatori e i tester a capire sia il risultato che l’output di una particolare interazione con l’utente.

1. Scenario – il comportamento che si intende descrivere
2. Given – lo stato iniziale dello scenario
3. When – un’azione specifica che l’utente compie
4. Then – un risultato testabile, di solito causato dall’azione in When
5. And – se necessario, continua una qualsiasi delle altre tre operazioni.

Prendiamo lo scenario della password descritto in precedenza:

1. Quando si imposta una password (Scenario),
2. Given che sono l’amministratore di un account,
3. WhenInserisco una password nel campo della password,
4. ThenDovrei essere avvisato dei requisiti della password,
5. And Dovrei essere autorizzato ad apportare subito delle correzioni,
6. Then che posso creare un account sicuro.

Ora abbiamo un quadro completo di chi sta eseguendo l’azione specifica e di quali sono i requisiti per i criteri di accettazione, e il team sa quali potrebbero essere le potenziali frustrazioni, in modo da garantire che il processo scorra più agevolmente.

In genere, il product manager o il product owner è responsabile della stesura delle storie Gherkin, creando così una migliore comunicazione tra il resto del team e assicurandosi che tutti si concentrino sui risultati, non solo sugli output.

Quali sono i vostri metodi preferiti per delineare le storie? Fatemi sapere! ✌️