Criteri di accettazione: come redigerli

I criteri di accettazione costituiscono il test di superamento o fallimento di una story, redatto prima dell’inizio dei lavori: i formati validi, gli esempi concreti e le differenze rispetto alla definizione di “completato”.

I criteri di accettazione sono le condizioni che una storia deve soddisfare per essere accettata: un test di superamento o fallimento, redatto prima che chiunque inizi a scrivere il codice. Non sono previsti punteggi parziali: o ogni criterio è soddisfatto o non lo è. 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 finisce per 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 affidare a un tester che non abbia mai partecipato alla vostra riunione di perfezionamento, e che saprebbe 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 è, poiché 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; cercate di evitare questa tendenza. Una lista di controllo è più veloce da leggere e più difficile da gonfiare quando la storia si riduce semplicemente a “queste cinque condizioni devono essere soddisfatte”.

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 utilità 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 risulta disabilitato.

Una guida su come “filtrare la tabella dei risultati”, redatta 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 cancellazione 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 scriva durante la definizione del backlog, insieme al team, 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 diversi aspetti 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 la 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 diventa lungo (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 e lasciarsi 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 questa 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 le user story. I punti che non superano il test di solito appartengono a una delle storie sopravvissute: rappresentano l’ambito di una storia che avete già separato, non un lavoro autonomo.

Il punto debole di questo approccio risiede nei criteri strettamente correlati: «il modulo convalida i dati inseriti e li salva nel database e visualizza 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 l’accuratezza del team.

Criteri di accettazione e requisiti

Un requisito indica cosa realizzare. Un criterio di accettazione indica come si potrà sapere di aver realizzato ciò che era necessario. «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 un’e-mail entro due minuti, 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 si riferiscono a ogni singola story; la definizione di “completato” è globale. I criteri sopra riportati descrivono ciò che la story relativa al login deve specificatamente garantire. La definizione di completamento (testata, sottoposta a revisione del codice, documentata, distribuita 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 consegnata. 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 termini di punti prive di criteri a sostegno, il che è un pio desiderio.

L’aggiunta di un criterio modifica la stima? A volte. Un criterio che mette in luce un lavoro nascosto (“deve essere accessibile agli screen reader”) di solito la modifica, 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 modificarla. L’ordine è importante: prima i criteri, poi i punti. Effettuare una stima prima che i criteri siano chiari equivale a effettuare una stima prima del perfezionamento, ed è la causa più comune di voti molto divergenti.

Scriva il test prima di iniziare il lavoro. Se un criterio non può risultare fallito, 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: si tratta di un test di superamento o meno, 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 meno.

Come si redigono i criteri di accettazione?

Scrivete ciascuna di esse come se dovesse essere consegnata a un tester che non ha mai visto lo 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 diversi 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 fare. La definizione di “completata” consiste in un’unica checklist generale che si applica a tutte le story (testata, revisionata, documentata, distribuita). 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