Modello di user story e criteri di accettazione

Il modello di user story consiste in una frase con tre spazi vuoti:

In qualità di [ruolo], desidero [obiettivo], in modo che [vantaggio].

Copiatelo, utilizzatelo, ma tenete presente a cosa serve: il modello è uno spunto per una conversazione, non un modulo da compilare. Una frase compilata è il punto da cui inizia il perfezionamento. Ciò che rende la storia realizzabile è ciò che viene aggiunto in seguito: i criteri di accettazione che trasformano un’intenzione concordata in un test di superamento/fallimento, e la stima che la trasforma in un lavoro pianificabile. Questo capitolo illustra una storia attraverso tutte e tre queste fasi.

Compilare gli spazi vuoti senza inventare nulla

Ogni slot presenta un errore di accensione ricorrente, e ogni errore di accensione è verificabile:

• [ruolo] — una persona specifica, mai “un utente”. Se non riusciste a individuare questa persona nei vostri dati analitici o nella vostra coda di assistenza, il ruolo è puramente decorativo. Verifica: un progettista potrebbe prendere una decisione diversa a causa del ruolo che avete scelto?
• [obiettivo] — ciò che la persona fa, secondo il proprio vocabolario. «Voglio reimpostare la mia password» appartiene all’utente; «Voglio un microservizio per la reimpostazione della password» appartiene al diagramma dell’architettura. Verifica: la persona direbbe davvero questa frase?
• [vantaggio] — l’argomento a favore della pianificazione del lavoro. Verifica: elimini la clausola. Se non si perde nulla, significa che il vantaggio non è stato ancora individuato.

La motivazione completa alla base di questo formato — comprese le tre “C” e la checklist INVEST che una user story completa dovrebbe soddisfare — è disponibile in Che cos’è una user story?. Sedici esempi concreti, positivi e negativi, sono riportati in Esempi di user story.

Una scheda di progetto copiata e incollata

La frase da sola non è sufficiente per avviare uno sprint. Ecco il modello completo della scheda che vale la pena adottare come standard: storia, criteri, limiti e, infine, la dimensione:

Story
  As a [role], I want [goal], so that [benefit].

Acceptance criteria (3–5, each pass/fail)
  - [ ] …
  - [ ] …
  - [ ] …

Out of scope
  - What this story deliberately does NOT cover.

Notes & dependencies
  - Designs, decisions, other teams, open questions.

Size: [added by the team, after the conversation — never before]

In quella scheda sono presenti due scelte deliberate. “Fuori dall’ambito” è un elemento fondamentale: la maggior parte delle discussioni sulla stima nasce dal fatto che due persone valutano ambiti diversi, e una sola riga qui impedisce che ciò accada. La stima viene per ultima: un numero scritto sul cartoncino prima che il team ne discuta diventa un punto di riferimento, il che costituisce il primo dei classici errori del planning poker.

Varianti del modello

Il modello classico è l’impostazione predefinita corretta, ma non è l’unica forma che funziona.

Variante	Forma	Lo utilizzi quando
Classic (Connextra)	In qualità di [ruolo], desidero [obiettivo], in modo che [vantaggio]	L’approccio predefinito per le attività rivolte agli utenti
Storia di un lavoro	Quando si verifica [situazione], desidero [motivazione], in modo da poter [risultato]	Il momento scatenante è più significativo del semplice ruolo sociale: la stessa persona, a bordo di un treno, desidera cose diverse rispetto a quando è seduta alla scrivania
I benefici prima di tutto	Al fine di [ottenere un vantaggio], in qualità di [ruolo], desidero [obiettivo]	Il team continua a redigere elenchi di vantaggi circolari; inserire la clausola all’inizio rende impossibile saltarla
Enunciato del problema in forma semplice	Una frase che descriva il problema, una che descriva il risultato, oltre ai criteri relativi alla data di completamento	Lavoro relativo alla piattaforma e agli aspetti tecnici in cui l’unico soggetto affidabile sarebbe la squadra stessa

L’ultima riga è più importante di quanto sembri. Alcune voci del backlog non contengono alcun riferimento all’utente nella frase, e fingere il contrario porta a formulazioni di riempimento del tipo «in qualità di sviluppatore, desidero che il framework venga aggiornato». La struttura del modello — una motivazione esplicita accompagnata da criteri verificabili — si applica a tale lavoro; la forma della frase, invece, non deve necessariamente essere rispettata.

Criteri di accettazione: la conferma riportata sulla scheda

I criteri di accettazione sono le condizioni di superamento o fallimento della story, definite prima dell’inizio dei lavori. Sulla scheda svolgono due funzioni: riportano quanto effettivamente concordato durante la discussione di affinamento e definiscono il traguardo verso cui sarà orientata la stima. Due formati coprono praticamente ogni story:

Una semplice lista di controllo, per le condizioni indipendenti:

• Il contenuto del carrello viene conservato per 30 giorni, indipendentemente dalla sessione.
• Un cliente abituale può visualizzare il carrello da qualsiasi dispositivo su cui abbia effettuato l’accesso.
• Un carrello svuotato rimane vuoto (gli articoli rimossi non vengono ripristinati).

Dato/Quando/Allora, per comportamenti che dipendono dallo stato:

• Se un cliente ha un carrello salvato, quando un articolo va esaurito, allora nel carrello l’articolo viene visualizzato in grigio con l’etichetta “esaurito”, anziché essere rimosso senza alcun avviso.

Utilizzate di default la checklist; ricorrete al modello “Dato che/Quando/Allora” quando la precondizione comporta un lavoro concreto. Limitate l’elenco a tre-cinque voci: un elenco più lungo indica solitamente che la storia dovrebbe essere suddivisa, e sono proprio i criteri a indicarvi i punti di suddivisione. Per un approfondimento completo (criteri vs requisiti, criteri vs definizione di completamento, chi li redige), consultate il capitolo sui criteri di accettazione.

Esempio pratico: un piano, modello per la stima

Ecco come si sviluppa una storia vera, utilizzando la scheda riportata sopra.

Fase 1 — la storia. Il product owner scrive:

Essendo un nuovo cliente, vorrei procedere al pagamento senza creare un account, in modo da poter completare l’acquisto prima di cambiare idea.

Fase 2 — la conversazione, trasposta in criteri. Nel corso del perfezionamento del backlog il team mette in luce gli aspetti che la frase non esprime esplicitamente e li annota:

• Un acquirente può completare la procedura di pagamento indicando solo l’indirizzo e-mail e i dati di spedizione, senza bisogno di una password.
• L’e-mail di conferma dell’ordine consente di creare un account con un solo clic (ordine già allegato).
• Il servizio di assistenza può individuare un ordine effettuato come ospite tramite il numero d’ordine e l’indirizzo e-mail.
• Il checkout come ospite prevede gli stessi controlli antifrode previsti per il checkout tramite account.

Escluso dall’ambito di applicazione: la conversione degli ordini storici degli ospiti quando un account viene creato in un secondo momento.

Fase 3 — Verifica dello stato di prontezza. Quattro criteri, un’esclusione esplicita, nessuna dipendenza non confermata: la story soddisfa la definizione di prontezza e viene trasmessa al team per la stima.

Fase 4 — la stima. Il team vota in un giro di planning poker. Vengono tirate le carte: 3, 5, 5, 8. L’8 spiega il motivo: il criterio relativo al controllo antifrode comporta un intervento sull’integrazione con il fornitore di servizi di pagamento, che nessun altro aveva considerato nella stima. È qui che i criteri svolgono la loro vera funzione: la discussione verte sull’ambito di lavoro, non su quale cifra sia quella corretta. Il team vota nuovamente e concorda sul numero 5.

Si noti l’ordine di procedura: prima i criteri, poi i punti. Una storia stimata prima che ne siano stati definiti i criteri genera scarti ampi e irrisolvibili che bloccano le sessioni di definizione delle dimensioni: il team si trova a votare su storie diverse che, per puro caso, condividono lo stesso titolo.

Domande frequenti

Che cos’è il modello di user story?

“In qualità di [ruolo], desidero [obiettivo], affinché [vantaggio].” Il ruolo indica chi ne trae valore, l’obiettivo definisce la capacità in termini comprensibili per quella persona, mentre il vantaggio rappresenta il motivo per cui il lavoro merita di essere inserito nel backlog. Il modello è uno spunto per una conversazione, non un modulo da compilare: è proprio riempiendo gli spazi vuoti che ha inizio il processo di perfezionamento.

Come si redigono i criteri di accettazione per una user story?

Elenchi da tre a cinque condizioni verificabili che indichino, con esito positivo o negativo, se la storia ha soddisfatto quanto concordato. Utilizzi una semplice lista di controllo quando le condizioni sono indipendenti e il modello “Dato che/Quando/Allora” quando il comportamento dipende dallo stato. Ciascun criterio dovrebbe essere verificabile da un tester che non abbia mai partecipato alla discussione di raffinamento.

Per i criteri di accettazione è preferibile utilizzare lo schema “Dato che/Quando/Allora” o una lista di controllo?

Adattate il formato al comportamento. Il modello “Dato che/Quando/Allora” si rivela utile quando l’esito dipende da uno stato iniziale, poiché vi obbliga a specificare la precondizione, il fattore scatenante e il risultato. Una lista di controllo è più veloce da leggere e più difficile da gonfiare quando la storia si riduce semplicemente a “queste quattro cose devono essere vere”. La maggior parte delle storie richiede solo la lista di controllo.

Che cos’è una “job story”?

Una variante che sostituisce la persona con una situazione: «Quando [situazione], desidero [motivazione], in modo da poter [risultato]». Le «job stories» derivano dalla scuola dei «jobs-to-be-done» e funzionano bene quando il momento scatenante spiega l’esigenza meglio di quanto non faccia una persona-tipo: la stessa persona desidera cose diverse quando è alla propria scrivania e quando si trova in treno.

Ogni elemento del backlog richiede il modello di user story?

No. Il modello descrive il valore percepito dall’utente, e applicarlo a attività legate alla piattaforma, a bug noti o a picchi di ricerca produce frasi che aggiungono formalità senza apportare informazioni. Mantenete i due elementi fondamentali che sono sempre validi — una motivazione esplicita e criteri di accettazione verificabili — e lasciate che la struttura della frase si adatti al lavoro specifico.

Letture correlate

• Stima agile: la guida completa — il punto di riferimento per tutto ciò che riguarda questo argomento.
• Che cos’è una user story? — il ragionamento alla base del modello: le tre C e INVEST.
• Esempi di user story — sedici user story commentate su cui basarsi per la calibrazione.
• Criteri di accettazione: come redigerli — il capitolo completo dedicato alla fase di conferma.
• Definizione di “pronto” — il controllo che una story basata su un modello deve superare per poter essere inserita nello sprint.
• Cosa sono gli story point? — l’unità di misura utilizzata per quantificare la carta completata.