Criteri di accettazione: come redigerli

I criteri di accettazione sono le condizioni che una storia deve soddisfare per essere accettata: un test di superamento/fallimento, redatto prima che chiunque inizi a programmare. Non sono previsti punteggi parziali: o vengono soddisfatti tutti o non lo sono affatto. Essi descrivono ciò che il risultato deve fare, non come realizzarlo. Inoltre, costituiscono un test, non una seconda descrizione della funzionalità. Se è possibile soddisfarli con un codice che non risolve il problema, non si tratta di criteri di accettazione, bensì di requisiti mascherati.

Ogni storia porta con sé una domanda implicita: come sapremo che è terminata? I criteri di accettazione rispondono a questa domanda in modo esplicito, prima ancora che il lavoro abbia inizio. Se definiti correttamente, la stima diventa più semplice, la demo si definisce da sé e il concetto di “completato” smette di essere oggetto di negoziazione. Se invece sono vaghi, si rischia di rilasciare una funzionalità su cui nessuno era d’accordo.

Cosa sono i criteri di accettazione e cosa non sono

Un buon criterio di accettazione è qualcosa che potreste consegnare a un tester che non abbia mai partecipato alle vostre riunioni di perfezionamento e che sappia esattamente cosa verificare. Esso descrive un risultato che l’utente può osservare, non l’implementazione che lo produce. «Utilizzare una cache Redis» non è un criterio di accettazione; è una soluzione. «I risultati vengono caricati in meno di un secondo per una tabella di 10.000 righe» lo è, perché chiunque può verificarlo e nessuno deve leggere il codice per farlo.

Inoltre, non si tratta di una lista di desideri. Ogni criterio deve essere falsificabile. Se una voce non può essere verificata (“la pagina è intuitiva”, “le prestazioni sono buone”), non è un criterio, ma una speranza. La elimini o la renda misurabile.

I due formati che funzionano

Utilizzate il formato Given/When/Then per i comportamenti che dipendono dallo stato e una semplice lista di controllo per un insieme di requisiti indipendenti. La maggior parte dei team tende a ricorrere al formato Given/When/Then per qualsiasi cosa; evitate di farlo. Una lista di controllo è più veloce da leggere e più difficile da gonfiare quando la storia si riduce semplicemente a «queste cinque cose devono essere vere».

Dato che / Quando / Allora

Dato uno stato iniziale, quando l’utente compie un’azione, il sistema risponde in un modo specifico. Questo formato dimostra la propria validità obbligando a definire tutti e tre gli elementi (la precondizione, il fattore scatenante e il risultato osservabile), che è esattamente ciò che un criterio approssimativo tralascia.

Esempi di criteri di accettazione

Una storia relativa alla procedura di accesso, redatta secondo lo schema “Dato che/Quando/Allora”:

• Se un utente registrato si trova sulla pagina di accesso, quando inserisce un indirizzo e-mail e una password corretti, allora viene reindirizzato alla propria dashboard.
• Se un utente registrato inserisce una password errata per tre volte, allora l’account viene bloccato per 15 minuti e l’utente può visualizzare il tempo rimanente.
• Se nella pagina di accesso il campo e-mail è vuoto, allora il pulsante di invio è disabilitato.

Un articolo sul tema “filtrare la tabella dei risultati”, redatto sotto forma di lista di controllo:

• Il filtro viene applicato al momento della selezione, senza un pulsante separato “Applica”.
• Due filtri si combinano con “AND”, non con “OR”.
• La rimozione di tutti i filtri ripristina l’elenco completo, non ordinato.
• Un insieme di risultati vuoto indica lo stato “nessuna corrispondenza”, non una tabella vuota.

Si noti ciò che entrambi tralasciano: il database, il framework, i nomi dei componenti. Indicano ciò che l’utente riceve, non come lo fornirete. E ogni riga rappresenta un elemento che un tester può approvare o bocciare senza dovervi porre alcuna domanda.

Come redigere i criteri di accettazione

• Li rediga durante la fase di perfezionamento del backlog, insieme al team, e non da solo in un secondo momento.
• Un risultato osservabile per riga. Se in una riga è presente un “e” che svolge una funzione concreta, si tratta di due criteri.
• Indichi il percorso non desiderato. Lo stato di vuoto, il timeout, l’input errato: è lì che si nasconde lo sforzo.
• Si concentrino sul comportamento, non sul design. Il mockup riguarda il layout; i criteri riguardano ciò che deve essere vero.
• Si fermi a circa cinque.

Quanti criteri di accettazione si considerano troppi?

Circa cinque. Non perché esista una regola, ma perché una storia che richiede dieci condizioni distinte e verificabili racchiude dieci elementi distinti di valore, il che significa che si tratta in realtà di diverse storie che fingono di essere una sola. Quando l’elenco si allunga, i criteri di accettazione costituiscono il punto di suddivisione.

Suddivisione in base ai criteri di accettazione

Se una storia presenta più di cinque criteri di accettazione, questi ultimi costituiscono solitamente l’unità di suddivisione. L’elenco è un backlog che funge da lista di controllo.

I criteri di accettazione servono a descrivere una storia. Non devono essere la storia stessa. Quando l’elenco si allunga (sei, otto, dieci punti), spesso il team ha già effettuato la suddivisione senza rendersene conto. Ogni criterio rappresenta una piccola porzione che il team potrebbe consegnare, presentare in demo e lasciare alle spalle. Considerare l’intero elenco come un unico impegno costringe il team ad affrontarlo tutto in una volta, il che rappresenta la peggiore combinazione di entità e rischio che si possa affidare a qualcuno in uno sprint.

Per effettuare la suddivisione, prendete ogni criterio e ponetevi la domanda che porreste per qualsiasi user story: il team lo rilascierebbe come elemento a sé stante? L’utente ne trarrebbe beneficio se fosse un elemento a sé stante? Potrebbe essere presentato in una demo? I punti che superano tale verifica sono delle user story. I punti che non superano il test di solito appartengono a una delle user story sopravvissute: costituiscono l’ambito di una user story che avete già separato, non un lavoro autonomo.

Il problema sorge quando si tratta di criteri strettamente correlati: «il modulo convalida i dati inseriti e li salva nel database e mostra una conferma». Questi tre elementi sembrano separabili, ma l’utente non ottiene nulla se ne viene realizzato solo uno. Non si tratta di una separazione in base ai criteri; è un’unica piccola storia, e i punti elencati riflettono semplicemente la meticolosità del team.

Criteri di accettazione e requisiti

Un requisito indica cosa realizzare. Un criterio di accettazione indica come si potrà verificare di aver realizzato ciò che era previsto. «Gli utenti possono reimpostare la propria password» è un requisito, e lo si può soddisfare con un flusso così mal concepito che nessuno riesce a portarlo a termine. «Un utente che richiede la reimpostazione riceve entro due minuti un’e-mail il cui link scade dopo un’ora» è un criterio di accettazione, poiché si tratta di un test che il flusso mal concepito non supera. I requisiti definiscono l’ambito del lavoro; i criteri ne determinano l’idoneità.

Criteri di accettazione e definizione di “completato”

Questi due concetti vengono costantemente confusi, mentre la distinzione è semplice: i criteri di accettazione sono per ogni story; la definizione di “completato” è globale. I criteri sopra riportati descrivono ciò che la story relativa al login deve specificatamente garantire. La definizione di «completato» (testato, sottoposto a revisione del codice, documentato, distribuito nell’ambiente di staging) si applica a ogni storia che il team consegna. Una storia può soddisfare i propri criteri di accettazione e tuttavia non essere ancora completa, poiché «funziona come specificato» e «pronta per il rilascio» sono due livelli diversi. Sono necessari entrambi.

Story point e criteri di accettazione

I criteri di accettazione descrivono il risultato: quali condizioni devono essere soddisfatte affinché la storia possa essere considerata rilasciata. I punti storia descrivono il percorso: l’entità del lavoro necessario per passare da «non disponiamo ancora di questo» a «i criteri sono soddisfatti». Si tratta di due assi distinti. Confonderli porta a criteri quantificati, il che è privo di significato, oppure a stime in punti prive di criteri a sostegno, il che è puramente auspicativo.

L’aggiunta di un criterio modifica la stima? A volte. Un criterio che mette in luce un carico di lavoro nascosto (“deve essere accessibile agli screen reader”) di solito lo fa, poiché identifica uno sforzo che era implicito. Un criterio che si limita a chiarire un presupposto esistente (“deve funzionare su Chrome e Safari”, quando questi sono sempre stati i browser supportati) non dovrebbe invece influire. L’ordine è importante: prima i criteri, poi i punti. Effettuare una stima prima che i criteri siano chiari equivale a stimare prima del perfezionamento, ed è la causa più comune di votazioni troppo generiche.

Scriva il test prima di iniziare il lavoro. Se un criterio non può fallire, non è un criterio. E se ne ha più di cinque, probabilmente ha più di una storia.

Domande frequenti

Cosa sono i criteri di accettazione?

I criteri di accettazione sono le condizioni che una storia deve soddisfare per essere accettata: un test di superamento/fallimento definito prima dell’inizio dei lavori. Essi descrivono ciò che il risultato deve fare, non come realizzarlo, e non è previsto alcun punteggio parziale: ogni criterio viene soddisfatto o non lo è.

Come si redigono i criteri di accettazione?

Scrivete ciascuna di esse come se dovesse essere consegnata a un tester che non abbia mai visto la story. Utilizzate la struttura “Dato che/Quando/Allora” per i comportamenti che dipendono dallo stato, oppure una semplice lista di controllo per una serie di requisiti indipendenti. Assicuratevi che siano verificabili, che si concentrino sui risultati e limitatevi a circa cinque. Se ne scrivete di più, vi ritroverete con diverse story.

Qual è la differenza tra criteri di accettazione e requisiti?

I requisiti indicano cosa realizzare; i criteri di accettazione indicano come si potrà verificare che sia corretto. Un requisito può essere soddisfatto da un codice che non coglie il punto. Un criterio di accettazione è un test: se viene superato, quella parte della storia è completata; se è possibile superarlo senza risolvere il problema dell’utente, si tratta di un requisito mascherato.

Qual è la differenza tra i criteri di accettazione e la definizione di “completato”?

I criteri di accettazione sono specifici per ogni story: descrivono ciò che quella particolare story deve garantire. La definizione di “completata” consiste in un’unica checklist globale che si applica a tutte le story (testata, revisionata, documentata, implementata). Una story può soddisfare i propri criteri di accettazione e tuttavia non essere considerata completata se non supera il controllo a livello di team.

Chi redige i criteri di accettazione?

Il Product Owner ne è responsabile, ma vengono redatti insieme al team durante la fase di affinamento. Il Product Owner definisce l’obiettivo finale; gli ingegneri e i tester individuano i casi limite. I criteri di accettazione redatti da soli, a posteriori, sono proprio quelli che tralasciano il caso che causa un errore in produzione.

Approfondimenti

• Stima agile: la guida completa: qui troverete tutte le informazioni necessarie.
• Definizione di “completato”: quella fase di controllo a livello di team con cui spesso si confondono i criteri di accettazione.
• Definizione di “pronto”: la lista di controllo che consente a una story di essere inserita nello sprint.
• Suddivisione delle user story: quando l’elenco dei criteri è troppo lungo.
• Affinamento del backlog: la cerimonia in cui vengono definiti criteri validi.