User story da un’intervista: modello e criteri di accettazione
Come scrivere una user story dalle parole del cliente: individuare il bisogno, conservare la fonte e aggiungere criteri di accettazione. Con esempio e modello.
Una user story descrive il valore per l’utente
Una user story descrive brevemente il risultato desiderato dal punto di vista di chi userà il prodotto. Una formula frequente è «Come [ruolo], voglio [azione] per [beneficio]». La formula avvia la discussione sul bisogno. Restano da definire i requisiti e la verifica del risultato.
La frase «aggiungete un pulsante verde» propone una soluzione. Per scrivere una story, scopri cosa cerca di fare la persona e cosa ostacola il percorso attuale. Conserva la frase per verificare la tua interpretazione.
Come utente, voglio un pulsante di esportazione grande e comodo da usare.
Come coordinatore di progetto, voglio trasmettere a un collega alcuni punti della riunione perché riceva solo le decisioni che lo riguardano.
Come scrivere una story da un’intervista
Scegli un episodio concreto
Trova il racconto dell’ultimo caso reale. Chi ha agito, con quale materiale e con quale obiettivo? Una frase come «a tutti servono i report» non basta per giustificare una story autonoma.
Annota le parole esatte e il contesto
Conserva il riferimento temporale e alcune frasi vicine. Separa le parole dell’intervistato dalla tua conclusione. Mantieni il carattere eccezionale delle situazioni che lo sono.
Formula ruolo, azione e beneficio
Il ruolo deve chiarire la situazione oltre la definizione generica di «utente». L’azione deve essere osservabile e il beneficio deve spiegare perché le serve.
Verifica il perimetro
Isola un risultato utile e compiuto, da discutere e verificare a parte. Evita di mettere in una sola story tutto il percorso dalla registrazione al report annuale.
Aggiungi i criteri di accettazione
Descrivi le condizioni che consentono di accertare il comportamento desiderato. Includi il caso principale e un’eccezione importante. Concorda i criteri con il team prima di considerarli requisiti.
Riporta in discussione le domande aperte
Se ruoli di accesso, quantità di dati o formato del risultato sono incerti, esplicita la domanda. Evita di colmare il vuoto con la soluzione più abituale.
Dalle parole del coordinatore alla scheda della story
Dopo la chiamata mando allo sviluppatore solo le attività che lo riguardano. Ora le copio a mano e temo di includere per errore anche commenti interni.
L’esempio riguarda un sistema fittizio di gestione delle note e non descrive funzionalità attuali di Transkribator. L’esigenza è condividere un estratto selezionato senza informazioni superflue. Il colore di un eventuale pulsante resta una scelta progettuale.
Story. Come coordinatore di progetto, voglio raccogliere i punti selezionati della riunione in un testo separato per trasmettere al responsabile solo le decisioni che lo riguardano.
Criteri proposti. Se vengono scelti tre punti, il risultato contiene esattamente quei tre. Prima di inviare, il coordinatore vede l’intero testo preparato. Se non è stato selezionato alcun punto, il sistema spiega che bisogna sceglierne.
Domanda aperta. Il testo deve contenere riferimenti temporali? L’intervista non lo chiarisce. Ne riparleremo al prossimo incontro prima di considerarlo un requisito.
La story ha una fonte, ma la sua importanza per la maggior parte dei clienti è ancora da verificare. Una registrazione racconta una sola esperienza. Per definire la priorità, valuta altre evidenze, obiettivi di prodotto e costi di realizzazione.
Come distinguere una story da un elenco di attività tecniche
«Creare una tabella nel database» o «aggiungere un gestore di eventi» sono attività tecniche. Possono far parte dell’implementazione, senza spiegare quale beneficio ottenga la persona. Anche una frase ben formulata non garantisce che il team comprenda tutti i vincoli.
Spiega la story a chi farà i test senza nominare un elemento dell’interfaccia. Se non riesci a dire che cosa fa la persona prima e dopo, torna all’intervista. Verifica anche i casi negativi: nessun dato selezionato, permessi insufficienti o un nuovo tentativo. Tieni solo le eccezioni rilevanti per questa story ed evita di estendere la scheda alla specifica dell’intero prodotto.
Scheda con fonte e domande aperte
Titolo della story: Ruolo e contesto di lavoro: Come [chi], voglio [azione] per [beneficio]. Fonte: intervista / data / riferimento temporale: Citazione originale: Nostra interpretazione: Criteri di accettazione: 1. In [condizione], la persona può [azione] e ottiene [risultato]. 2. Se [eccezione importante], avviene [comportamento atteso]. Fuori dal perimetro della story: Punti da chiarire: Chi ha confermato la formulazione e quando:
- Il ruolo è preciso e il beneficio è chiaro.
- La citazione è separata dalla soluzione del team.
- I criteri si possono verificare osservando il comportamento.
- Le domande rimangono esplicite.
Entriamo nei dettagli
Bisogna sempre scrivere «Come… voglio… per…»?
La formula è una traccia. Conta che il team capisca chi agisce, che cosa vuole fare e perché.
Quanti criteri di accettazione servono?
Quanti bastano per lo scenario principale e le eccezioni importanti. Se riguardano risultati autonomi, può essere opportuno dividere la story.
Si può creare una story da una sola intervista?
Puoi preparare un’ipotesi e citarne la fonte. Una sola intervista non basta per dimostrare un bisogno di tutto il segmento o per avviare automaticamente lo sviluppo.