Storie utente efficaci

Nello sviluppo agile, abbiamo cambiato l'approccio dalla creazione di "caratteristiche" alla fornitura di "valore" all'utente.

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

Non si tratta di specifiche tecniche dettagliate, ma di brevi descrizioni di una funzionalità raccontata dal punto di vista dell'utente, spiegando chi ha bisogno di qualcosa, di cosa ha bisogno e perché ne ha bisogno.

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

Come Agile Coach, insegnare al team, e in particolare al Product Owner, a scrivere e utilizzare le storie utente in modo efficace è fondamentale.

Formato (Come , voglio , per )

Il formato piú comune per scrivere le user story segue un modello semplice ma efficace:

Come , voglio , per .

Come : identifica chi trarrà vantaggio dalla storia (ad esempio, "acquirente abituale", "amministratore", "utente non registrato").

A volte, l'"utente" puó essere anche un sistema interno, ma deve sempre collegarsi in ultima analisi al valore per l'utente finale.

Voglio : descrive ció che l'utente vuole essere in grado di fare.

Deve essere l'obiettivo reale dell'utente, non un'azione intermedia (ad esempio, "ricevere notifiche" invece di "premere un pulsante rosso").

Affinché : spiega la motivazione alla base dell'obiettivo, il valore che l'utente si aspetta di ottenere. Questa parte è fondamentale per comprendere l'importanza e dare priorità alla storia.

Esistono altri modelli (come Chi-Cosa-Perché), ma tutti cercano di catturare questi tre componenti essenziali.

Concentrarsi sul problema, non sulla soluzione

Una buona user story 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 proprietario del prodotto e altri stakeholder, trovare il modo migliore per implementare la soluzione.

Ad esempio, invece di chiedere di "creare un chatbot" (soluzione), la storia potrebbe essere "Come utente con problemi tecnici, desidero ottenere assistenza immediata per risolvere rapidamente il mio problema" (problema).

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

Criteri di accettazione (Dato-Quando-Allora)

Per garantire che una user story sia stata implementata correttamente e risolva il problema previsto, vengono utilizzati 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 Fatto (DoD), che è generale per tutto il lavoro, gli AC sono unici per ogni storia utente.

Un formato comune per scrivere gli AC è Dato-Quando-Allora (Given-When-Then):

• Dato (Given): stabilisce il cont