Cosa sono i criteri di accettazione? Esempi e best practice

I criteri di accettazione favoriscono una comunicazione chiara e aiutano a definire le aspettative. Delineano le condizioni specifiche che una funzionalità o user story deve soddisfare per essere davvero completa e sono talvolta chiamati collettivamente "definizione di 'completato'".

Qual è il segreto per creare un software che offre risultati concreti? Se sei un product manager o un owner di prodotto, definire perfettamente i criteri di accettazione è la chiave per sviluppare funzionalità che centrano l'obiettivo.

Senza dei criteri di accettazione chiari, i team rischiano di andare incontro a confusione, obiettivi non raggiunti e sprechi di energie. Ma cosa sono di preciso i criteri di accettazione e come puoi scriverli in maniera efficace?

In questo articolo, analizzeremo nel dettaglio cosa sono i criteri di accettazione, forniremo esempi concreti, spiegheremo in cosa si differenziano dalle user story, perché sono importanti per il processo di sviluppo e come scriverne di propri.

Cosa sono i criteri di accettazione?

I criteri di accettazione sono le condizioni che un prodotto, una user story o un incremento di lavoro devono soddisfare per essere completi. Sono una serie di affermazioni chiare, concise e verificabili che si concentrano sulla fornitura di risultati positivi per i clienti.

Anziché concentrarsi su come raggiungere una soluzione, i criteri di accettazione rappresentano il risultato finale desiderato del task.

Sono visti come i requisiti predefiniti nelle metodologie Agile, in particolare quelli che una user story deve soddisfare per essere considerata completa. Inoltre, fungono da documentazione dei requisiti Agile che delinea le condizioni che devono essere soddisfatte affinché la consegna sia considerata riuscita.

Differenza tra criteri di accettazione e user story

I criteri di accettazione e le user story vengono spesso discussi insieme, ma svolgono ruoli fondamentalmente diversi nello sviluppo del prodotto. Comprendere questa distinzione è fondamentale per redigere un backlog che sia al contempo incentrato sull'utente e pronto per la consegna.

• Le user story definiscono il "perché" e comunicano lo scopo e il valore di una funzionalità dal punto di vista dell'utente.

• I criteri di accettazione definiscono "cosa determina la buona riuscita di un progetto" e traducono tale scopo in requisiti espliciti e verificabili per l'implementazione.

Una user story ben realizzata cattura l'esigenza del cliente, il comportamento previsto e la motivazione alla base. Questa strutturazione ancora gli elementi del backlog al reale valore per l'utente e fornisce un contesto essenziale per il backlog grooming e la definizione delle priorità.

Ad esempio, le user story potrebbero essere:

• Come cliente, desidero cercare i prodotti per nome, in modo da poter trovare facilmente gli articoli che sto cercando.

Questa story definisce la direzione, senza specificare i dettagli dell'implementazione.

Tuttavia, i criteri di accettazione trasformano l'intento in condizioni chiare e verificabili che determinano se la story è completata. Allineano il tuo team sull'ambito, eliminano le ambiguità e forniscono uno standard misurabile per il controllo di qualità e gli stakeholder. Questi potrebbero includere:

• La funzione di ricerca restituisce risultati che corrispondono esattamente al nome del prodotto inserito.

• La funzione di ricerca restituisce risultati che corrispondono parzialmente al nome del prodotto inserito.

• I risultati vengono visualizzati in un formato chiaro, organizzato e intuitivo.

Insieme, garantiscono che il tuo team sviluppi la cosa giusta nel modo giusto.

Caratteristiche dei buoni criteri di accettazione

Dei criteri di accettazione di alta qualità condividono diverse caratteristiche chiave che li rendono facili da comprendere, convalidare e applicare durante la consegna. Tra le caratteristiche comuni ci sono:

Chiarezza e brevità

Di' esattamente ciò che intendi e dillo in modo semplice. Scrivi i criteri di accettazione in un linguaggio semplice e inequivocabile che tutti gli stakeholder (sviluppo, controllo di qualità, design e prodotto) possano interpretare allo stesso modo.

Assicurati che siano concisi e orientati ai risultati. Evita il gergo tecnico e qualsiasi espressione che lasci spazio all'interpretazione.

Verificabilità

Ogni criterio deve essere oggettivamente verificabile e deve corrispondere in modo univoco a uno o più test eseguibili che confermino oggettivamente se il requisito è soddisfatto.

La verificabilità elimina ogni soggettività e impone a tutti di essere onesti su cosa significhi realmente "completato".

Risultato

Descrivi il risultato, non la ricetta. Dei criteri efficaci spiegano come deve essere l'esperienza della persona, non i passaggi tecnici necessari per svilupparla.

In questo modo, il team tecnico ha lo spazio necessario per risolvere i problemi, garantendo al contempo che il comportamento finale sia in linea con le aspettative degli utenti.

Misurabilità

Quando possibile, quantifica le aspettative per creare una soglia definitiva di superamento/mancato superamento. In questo passaggio, la precisione accelera i test e riduce la necessità di rilavorazioni.

Sostituisci le affermazioni vaghe come "La pagina dei risultati dovrebbe avere un bell'aspetto" con affermazioni misurabili come "Ogni immagine del prodotto viene visualizzata con una risoluzione minima di 300×300 pixel".

Indipendenza

Ogni criterio dovrebbe essere indipendente dagli altri. I criteri indipendenti semplificano i test, riducono le associazioni e rendono più facile diagnosticare i problemi quando qualcosa non funziona.

Se i criteri indipendenti non hanno senso, probabilmente occorre riscriverli.

Perché hai bisogno dei criteri di accettazione?

I criteri di accettazione sono fra gli strumenti più efficaci che hai per favorire la chiarezza, ridurre il tasso di abbandono e assicurarti di consegnare effettivamente quello che secondo te stavi realizzando. Ecco perché meritano un posto fisso all'interno del processo.

• Allineamento e comprensione condivisa: quando definisci chiaramente come riconoscere il successo, tutti, dal team di progettazione quello del controllo di qualità fino agli stakeholder, dispongono delle stesse informazioni, quindi non devo fare supposizioni che potrebbero causare sorprese. I criteri di accettazione sono una sorta di contratto condiviso che stabilisce cosa stai realizzando e perché.

• Ambiguità e rilavorazioni ridotte: una chiara DoD (Definition of Done, definizione di completato) è il percorso più veloce per prevenire le rilavorazioni. Aspettative vaghe portano a iterazioni infinite, mentre criteri espliciti impediscono interpretazioni soggettive (e lo slittamento dell'ambito). La chiarezza iniziale comporta costi sempre ridotti rispetto a una correzione successiva.

• Maggiore efficienza nei test: criteri di accettazione ben definiti forniscono sostanzialmente al controllo di qualità un modello per i test. Si traducono direttamente in passaggi verificabili, che permettono di valutare semplicemente se la funzionalità soddisfa le aspettative o di individuare dove non lo fa.

• Gestione migliorata dei progetti: per i project manager, i criteri di accettazione sono preziosissimi. Suddividono una funzionalità in checkpoint misurabili, rendendo visibili i progressi e riducendo i rischi. Ogni criterio spuntato dall'elenco è un passo tangibile verso la consegna.

• Maggiore soddisfazione degli stakeholder: quando le funzionalità soddisfano costantemente le aspettative, gli stakeholder si fidano del processo e del prodotto. Criteri di accettazione chiari stabiliscono aspettative realistiche, riducono al minimo l'ambiguità e aiutano a fornire risultati che soddisfano realmente le esigenze degli utenti.

I criteri di accettazione colmano il divario tra visione ed esecuzione. Trasformano l'intento in allineamento, l'allineamento in azione e l'azione in consegna affidabile.

Se vuoi che i team siano reattivi e realizzino quanto desiderato, i criteri di accettazione sono imprescindibili.

Come redigere i criteri di accettazione

La creazione di criteri di accettazione ben definiti è essenziale per il successo dello sviluppo software. Ecco alcuni passaggi chiave e suggerimenti per maggiori informazioni:

1. Inizia con la user story

Fai riferimento alla user story collegata ai criteri di accettazione. Questo garantisce che i criteri siano collegati alla funzionalità desiderata.

2. Determina i risultati

Chiarisci l'esperienza utente e i criteri di risultato previsti. Quali risultati deve raggiungere la funzione per l'utente? Evita di impantanarti nei dettagli tecnici di implementazione.

3. Stabilisci la testabilità complessiva

Assicurati che ogni criterio si traduca in un test chiaro e verificabile. Questo permette di effettuare una valutazione obiettiva della conformità della funzione ai requisiti.

4. Definisci la misurabilità

Quando possibile, quantifica i criteri in termini misurabili. In questo modo è possibile determinare chiaramente il superamento o il mancato superamento di un test.

5. Concentrati sull'indipendenza

Punta a criteri indipendenti che puoi testare separatamente. Questo semplifica il processo di test ed evita le dipendenze.

Considera di incorporare i criteri del test di accettazione utente (UAT) insieme ai criteri del team di sviluppo. I criteri UAT si concentrano sulla garanzia che la funzionalità soddisfi le aspettative dal punto di vista dell'usabilità.

6. Promuovi la collaborazione

Incoraggia la collaborazione durante il processo di creazione. Coinvolgi l'owner di prodotto, lo sviluppatore software (o i team di sviluppo) e gli altri stakeholder per garantire una serie completa di criteri che rifletta tutti i punti di vista.

7. Rivedi e perfeziona

Non aver paura di rivedere e perfezionare i criteri di accettazione durante lo sviluppo. Man mano che la comprensione si evolve, valuta la possibilità di modificare i criteri in modo che riflettano le informazioni più recenti.

8. Offri chiarezza e concisione

Punta a un linguaggio chiaro e conciso che tutti possano capire. Il gergo tecnico o le frasi ambigue possono creare confusione.

Chi dovrebbe redigere i criteri di accettazione?

La stesura dei criteri di accettazione nei flussi di lavoro Agile e negli ambienti della metodologia è un'attività collaborativa, non individuale. Di seguito è riportata una ripartizione dei ruoli tipici.

• Owner di prodotto: possiede una profonda comprensione delle esigenze dei clienti e della visione del prodotto e svolge un ruolo cruciale nell'avviare la discussione e nel delineare la funzionalità desiderata.

• Team di sviluppo: usa le sue competenze tecniche per fornire informazioni preziose sulla fattibilità e sulla testabilità dei criteri. Suggerisce modi appropriati per inquadrare i criteri per una valutazione chiara.

• Scrum master (se applicabile): un facilitatore che guida la discussione del team e assicura che tutti abbiano voce in capitolo. Contribuisce anche a garantire che i criteri aderiscano alle best practice.

Sebbene l'owner di prodotto possa avviare il processo, i criteri finali devono essere un'attività collettiva che integra tutte le prospettive degli stakeholder.

Questo approccio collaborativo favorisce una comprensione condivisa e aumenta la probabilità di fornire un prodotto di successo.

Esempi di criteri di accettazione

Di seguito sono riportati alcuni esempi precisi di criteri di accettazione ben scritti. Ognuno collega chiaramente una user story a condizioni specifiche e misurabili che determinano la "definizione di completato".

Esempio 1: ricerca del prodotto

• User story: Come cliente, desidero cercare i prodotti per nome, in modo da poter trovare facilmente gli articolo che sto cercando.

• Criteri di accettazione:

  • Il sistema restituisce tutti i prodotti che corrispondono esattamente al termine di ricerca inserito.

  • Il sistema restituisce corrispondenze parziali quando l'utente inserisce almeno tre caratteri.

  • I risultati di ricerca mostrano il nome, l'immagine e il prezzo del prodotto in un layout chiaro e organizzato.

  • La pagina dei risultati di ricerca consente l'impaginazione e mostra un massimo di 20 elementi.

  • Se non vengono trovati risultati, il sistema visualizza un messaggio "Nessun risultato trovato" e alcuni passaggi successivi utili.

Esempio 2: modifica delle informazioni dell'account

• User story: Come utente registrato, voglio modificare le informazioni del mio account in modo che il mio profilo sia sempre aggiornato.

• Criteri di accettazione:

  • Gli utenti possono accedere alla sezione Modifica profilo nelle impostazioni del proprio account.

  • Gli utenti possono aggiornare nome, cognome, indirizzo e-mail e numero di telefono.

  • Il sistema convalida i campi obbligatori e visualizza errori in caso di informazioni non valide o mancanti.

  • Se si clicca su Salva, le informazioni dell'utente vengono aggiornate correttamente nel sistema.

  • Una volta completato l'aggiornamento, il sistema visualizza un messaggio di conferma.

  • Se l'aggiornamento non va a buon fine, il sistema visualizza un messaggio di errore utilizzabile.

Esempio 3: report sulle attività dell'utente

• User story: Come amministratore, voglio generare report sull'attività per monitorare l'attività e il coinvolgimento degli utenti.

• Criteri di accettazione:

  • La dashboard di amministrazione include una sezione Report dedicata.

  • Gli amministratori possono generare report sulle attività chiave degli utenti, tra cui accessi, prodotti visualizzati e acquisti.

  • I report possono essere filtrati per intervallo di date e tipo di utente.

  • Gli amministratori possono esportare i report in almeno due formati, tra cui CSV e PDF.

  • Il sistema visualizza un messaggio di errore chiaro se non è possibile generare un report.

Questi esempi dimostrano come saldi criteri di accettazione trasformano le user story in requisiti attuabili e testabili. Quando i team seguono questa struttura, forniscono funzionalità che soddisfano costantemente le aspettative degli utenti e riducono l'ambiguità nell'intera fase di sviluppo.

Scrivi criteri di accettazione chiari con l'aiuto di una piattaforma centralizzata

Quando tutti lavorano da uno spazio centralizzato, è molto più facile sviluppare, monitorare e condividere i criteri di accettazione. È per questo che un numero così elevato di team usa Jira per gestire i criteri di accettazione.

Sono facili da inserire direttamente nella descrizione della story o nel campo Criteri di accettazione. Inoltre, gli strumenti di formattazione di Jira, come gli elenchi puntati e le caselle di controllo, aiutano i team a monitorare i progressi e a definire requisiti costantemente chiari.

Oltretutto, puoi allegare progetti o includere link alla documentazione di Confluence per assicurarti che tutto il contesto rilevante sia facilmente accessibile. Se hai bisogno di aiuto per scrivere criteri di accettazione più coerenti e completi, la soluzione IA di Jira, Rovo, identifica le lacune e suggerisce miglioramenti.

Tutte queste funzionalità e tutti questi strumenti insieme riducono l'ambiguità e favoriscono un processo di sviluppo più fluido. Inizia oggi stesso.

Domande frequenti sui criteri di accettazione

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

I criteri di accettazione e la definizione di "completato" sono fondamentali per il successo del progetto, ma hanno scopi diversi. Mentre i criteri di accettazione si concentrano sulle funzionalità specifiche che una user story deve soddisfare per essere completa per l'utente finale,

la definizione di "completato" stabilisce una serie più ampia di standard di qualità per tutti i lavori di sviluppo, che comprendono aspetti non funzionali come la qualità del codice e la documentazione.

In sostanza, i criteri di accettazione definiscono cosa deve succedere per una user story, mentre la definizione di "completato" delinea gli standard di qualità generali delle modalità in cui un team deve svolgere il lavoro.

Quando si dovrebbero delineare i criteri di accettazione?

Dipende, ma ci sono alcuni momenti chiave da considerare. Un'opzione è identificare i criteri iniziali durante le sessioni di affinamento del backlog, quando il team discute e approfondisce le user story.

Un altro momento adatto potrebbe essere durante la pianificazione dello sprint, quando il team collabora per finalizzare i criteri di accettazione per le user story previste per lo sprint successivo. I criteri sono così aggiornati e riflettono le conclusioni più recenti.

Definire i criteri di accettazione prima dell'inizio dello sviluppo consente di avere aspettative chiare e un processo di sviluppo regolare.

Quali sono alcune sfide legate alla stesura dei criteri di accettazione?

Una sfida che i team si trovano spesso ad affrontare è l'ambiguità dei criteri, che può portare a interpretazioni errate, oppure la difficoltà nel trovare un equilibrio tra criteri troppo specifici e troppo vaghi.

Inoltre, gli stakeholder potrebbero trovarsi in disaccordo sulla definizione di "completato" e ostacolare così il corretto svolgimento del processo. Infine, sebbene sia una prospettiva allettante, coprire ogni dettaglio può portare a criteri di accettazione ingombranti e alla fine inefficaci.