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], affinché [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 le fasi.

Compilare gli spazi vuoti senza inventare nulla

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

• [ruolo]: una persona specifica, mai “un utente”. Se non riuscisse a individuare questa persona nei Suoi dati analitici o nella Sua coda di assistenza, il ruolo è puramente decorativo. Verifica: un progettista potrebbe prendere una decisione diversa a causa del ruolo che ha scelto?
• [obiettivo]: ciò che la persona fa, secondo il suo 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 effettivamente questa frase?
• [vantaggio]: la motivazione alla base della pianificazione del lavoro. Verifica: elimini la clausola. Se non si riscontra alcuna perdita, 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 su cui vale la pena basarsi, con la descrizione, i criteri, i limiti e, infine, le dimensioni:

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 relative alle stime nasce dal fatto che due persone valutano ambiti diversi, e una sola riga in questo contesto impedisce che ciò accada. La stima viene per ultima: un numero scritto sulla scheda prima che il team ne discuta diventa un punto di riferimento fisso, 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], affinché [vantaggio]	L’impostazione predefinita 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 ruolo sociale (la stessa persona su 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 benefici 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	Attività relative 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 più criteri verificabili) si applica a tale lavoro; la forma della frase, invece, non deve necessariamente seguire tale struttura.

Criteri di accettazione: la conferma riportata sulla scheda

I criteri di accettazione rappresentano le condizioni di superamento o fallimento della story e vengono definiti prima dell’inizio dei lavori. Sulla scheda svolgono due funzioni: riportano quanto effettivamente concordato durante la discussione di perfezionamento 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 tra una sessione e l’altra.
• 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:

• Dato un cliente con un carrello salvato, quando un articolo va esaurito, allora nel carrello l’articolo viene visualizzato in grigio con l’etichetta “esaurito”, anziché essere rimosso in modo silenzioso.

Utilizzate la checklist come impostazione predefinita; ricorrete al metodo “Dato/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 i criteri vi indicano i punti di separazione. 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 il percorso che segue 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 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 fornendo 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 del 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: la verifica di prontezza. Quattro criteri, un’esclusione specificata, nessuna dipendenza non confermata: la story soddisfa la definizione di prontezza e viene inoltrata 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 viene spiegato: il criterio relativo al controllo delle frodi comporta l’intervento sull’integrazione con il fornitore di servizi di pagamento, cosa 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 procedere: 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 finisce per 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 ottiene il valore, l’obiettivo definisce la capacità in termini comprensibili per quella persona e 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 nel riempire gli spazi vuoti che ha inizio il processo di affinamento.

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

Indichi da tre a cinque condizioni verificabili che stabiliscano, con esito positivo o negativo, se la storia abbia 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 affinamento.

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 del “jobs-to-be-done” e funzionano bene quando il momento scatenante spiega l’esigenza meglio di quanto non faccia una persona. 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 per l’utente, e applicarlo forzatamente al lavoro su 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 trasferibili (una motivazione esplicita e criteri di accettazione verificabili) e lasciate che la struttura della frase si adatti al lavoro.

Approfondimenti

• 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 il principio 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 “ready”: il passaggio che una story basata su un modello deve superare per entrare nello sprint.
• Cosa sono gli story point?: l’unità di misura utilizzata per quantificare la scheda completata.