Storie utente efficaci

Nello sviluppo agile, spostiamo l’attenzione dal realizzare «funzionalità» al fornire «valore» all’utente.

Le storie utente sono lo strumento principale per descrivere il lavoro da questa prospettiva incentrata sul valore.

Non sono specifiche tecniche dettagliate, ma brevi descrizioni di una funzionalità raccontate dal punto di vista dell’utente, che spiegano chi ha bisogno di qualcosa, di cosa ha bisogno e perché.

Aiutano il team a comprendere il contesto e lo scopo del lavoro, favorendo la conversazione e la collaborazione per trovare la soluzione migliore.

In qualità di Agile Coach, insegnare al team, e in particolare al Product Owner, a scrivere e utilizzare efficacemente le storie utente è fondamentale.

Formato (Come, voglio, affinché)

Il formato più comune per scrivere le storie utente segue un modello semplice ma efficace:

Come…, voglio…, affinché…

Come: identifica chi trarrà beneficio dalla storia (ad es., «acquirente abituale», «amministratore», «utente non registrato»).

A volte, l’«utente» può essere persino un sistema interno, ma deve sempre essere collegato, in ultima istanza, al valore per l’utente finale.

Voglio: descrive ciò che l’utente vuole poter fare.

Dovrebbe essere l’obiettivo effettivo dell’utente, non un’azione intermedia (ad es., «ricevere notifiche» invece di «premere un pulsante rosso»).

Affinché: spiega la motivazione alla base dell’obiettivo, ossia il valore che l’utente si aspetta di ottenere. Questa parte è fondamentale per comprenderne l’importanza e stabilire la priorità della storia.

Esistono altri modelli (come Chi-Cosa-Perché), ma tutti mirano a cogliere questi tre componenti essenziali.

Concentrarsi sul problema, non sulla soluzione

Una buona storia utente descrive il problema che l’utente deve risolvere o l’obiettivo che vuole raggiungere, senza prescrivere la soluzione tecnica.

È responsabilità del team di sviluppo, in collaborazione con il Product Owner e gli altri portatori di interesse, trovare il modo migliore per realizzare la soluzione.

Per esempio, invece di chiedere «creare un chatbot» (soluzione), la storia potrebbe essere «Come utente con problemi tecnici, voglio ricevere assistenza immediata per risolvere rapidamente il mio problema» (problema).

Questo approccio favorisce l’innovazione e la creatività, consentendo al team di esplorare diverse soluzioni (forse una sezione FAQ migliorata è più efficace di un chatbot) e di concentrarsi sulla fornitura del valore reale di cui l’utente ha bisogno.

Criteri di accettazione (Dato-Quando-Allora)

Per assicurarsi che una storia utente sia stata implementata correttamente e risolva il problema previsto, si utilizzano i criteri di accettazione (AC).

Si tratta di un insieme di condizioni specifiche e verificabili che devono essere soddisfatte affinché la storia sia considerata «completata».

A differenza della Definizione di Completato (DoD), che è generale e si applica a tutto il lavoro, i criteri di accettazione sono specifici per ogni storia utente.

Un formato comune per scrivere i criteri di accettazione è Dato-Quando-Allora (Given-When-Then):

• Dato (Given): stabilisce il contes