Criteri di accettazione: come redigerli

I criteri di accettazione costituiscono il test di superamento o meno 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 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 progetto nasconde una domanda implicita: come sapremo quando sarà completato? I criteri di accettazione forniscono una risposta esplicita a tale domanda, 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 affidare 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. Eliminatela oppure rendetela 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 ricorre 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ò vedere quanto tempo manca alla fine del blocco.
  • Se nella pagina di accesso il campo e-mail è vuoto, allora il pulsante di invio è 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 — non è presente un pulsante “Applica” separato.
  • 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 scriva durante la definizione del backlog, insieme al team — non da solo, a posteriori.
  • Un risultato osservabile per riga. Se in una riga è presente un “e” che svolge una funzione concreta, si tratta di due criteri.
  • Indicate 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 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 volume e rischio che si possa affidare a qualcuno in uno sprint.

Per procedere alla 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? Si potrebbe mostrarne 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 storie sopravvissute: si tratta di aspetti relativi a una storia che avete già separato, non di 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 servono semplicemente a garantire la completezza del lavoro da parte 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 necessario. «Gli utenti possono reimpostare la propria password» è un requisito — ed è possibile soddisfarlo con un flusso così mal concepito che nessuno lo porta 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 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 completata, 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: ciò che deve verificarsi 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 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 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ò 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: si tratta di 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 meno.

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 “Given/When/Then” per i comportamenti che dipendono dallo stato, oppure una semplice lista di controllo per una serie di requisiti indipendenti. Assicuratevi che siano testabili, 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 generale 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.

Letture correlate