Come Scrivere Criteri di Accettazione Eccellenti (Con Esempi)
Quante volte hai visto sviluppatori e tester discutere su come dovrebbe funzionare una determinata funzionalità? E che dire delle facce confuse degli sviluppatori che non erano sicuri di come costruire la funzionalità che avevi richiesto? Entrambi sono problemi abbastanza comuni nel mondo del software e, fortunatamente, hai uno strumento potente nel tuo arsenale per risolverli: i criteri di accettazione.
In questa guida, analizzerò la natura di questo formato per scrivere i requisiti, spiegherò il loro ruolo nella gestione del prodotto e ti mostrerò come scrivere ottimi criteri di accettazione.
Indice dei Contenuti
Cosa sono i Criteri di Accettazione?
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Qual è lo Scopo di Scrivere Criteri di Accettazione?
Come Dovrebbero Essere Scritti Bene i Criteri di Accettazione?
Formati Comuni dei Criteri di Accettazione
Cosa Sono i Criteri di Accettazione
(e Dove si Collocano in Agile/Scrum?)
Nella metodologia Agile, un criterio di accettazione è la più piccola unità di requisito funzionale o di design che i product manager Agile (o analisti di business) aggiungono alle loro storie per comunicare chiaramente i diversi stati e comportamenti delle funzionalità che il team intende sviluppare.
Tecnicamente, puoi usare i criteri di accettazione dove vuoi. Tuttavia, tradizionalmente fanno parte delle user story, che sono componenti degli epic Agile.
Per comprendere meglio i criteri di accettazione, rinfreschiamo prima la memoria e rivediamo gli elementi di questa gerarchia per vedere a cosa serve ciascuno di essi.
Epic
Gli epic sono attività che contengono requisiti funzionali e non funzionali di alto livello di una funzionalità ampia oppure di un gruppo di funzionalità correlate tra loro. Di solito, un epic riguarda un intero caso d'uso per i tuoi clienti e include tutte le funzionalità sottostanti che devi implementare per coprire quel caso d'uso.
Immagina di far parte del team di prodotto di Spotify e di voler ampliare l'utilizzo dell'app aggiungendo un nuovo caso d'uso per le persone che sono in movimento e non hanno accesso a Internet.
Per coprire questo caso d'uso, potresti considerare di aggiungere una nuova grande funzionalità chiamata “modalità offline per Spotify”, che diventerebbe un epic nel backlog di prodotto contenente tutti i requisiti generali per permettere agli utenti di ascoltare musica senza connessione, oltre a diverse user story con i requisiti delle singole parti di questa funzione.
User Story
Le user story sono più piccole e rappresentano una singola funzionalità distinta all’interno dell’epic. Sono compiti gestibili sui quali il team Agile può impegnarsi a consegnare in una singola iterazione.
Una delle caratteristiche chiave di una user story è che la funzionalità che rappresenta deve essere qualcosa di completo e potenzialmente utilizzabile.
Ad esempio, se stai sviluppando un’app di archiviazione file online e vuoi consentire agli utenti di rinominare i file caricati, sarà necessario intervenire sia sul frontend (UI e esperienza utente nella rinomina) che sul backend (salvando il nuovo nome).
Affinché la funzionalità sia completa e utilizzabile, sarà necessario terminare entrambi i compiti e collegare la parte frontend e backend tra loro. Il tuo team dovrebbe svolgere tutto ciò nell’ambito della stessa user story.
Se dovessi lavorare solo sul backend, il relativo compito non costituirebbe una vera user story perché avrebbe una consegna non completa e non utilizzabile.
Per far capire al team di sviluppo come sarà la funzione e come dovrà comportarsi, i product owner scrivono i criteri di accettazione per quella storia.
Criteri di Accettazione della User Story
Infine, abbiamo gli elementi più piccoli nella gerarchia dei requisiti di prodotto software: i criteri di accettazione. Essi rappresentano scenari d’uso individuali di quella funzionalità o informazioni che il team di ingegneria reputa importanti per l’implementazione della storia.
Nell’esempio sopra, un criterio di accettazione potrebbe essere l’apertura di un campo di testo con il nome del file già compilato se l’utente clicca sul pulsante ✏️Rinomina presente sul file caricato.
Definition of Done (Sì, è Diversa dai Criteri di Accettazione!)
A volte i product owner (soprattutto quelli relativamente nuovi in questo ruolo scrum) confondono la definition of done con i criteri di accettazione.
Onestamente, all’inizio anche per me era piuttosto confuso, perché entrambi sono “criteri per verificare se la funzionalità è completa".
L'unica differenza è che la definizione di fatto rappresenta la completezza in termini dei processi di sviluppo del team.
Mentre i criteri di accettazione rappresentano i requisiti funzionali (come la funzionalità deve apparire e comportarsi).
Questo significa che la definizione di fatto rimarrà invariata per tutte le storie che il team sta implementando, a meno che non decidano di apportare modifiche durante le retrospettive. I criteri di accettazione, invece, sono unici per ciascuna storia perché spiegano come quella funzionalità deve funzionare.
Nota: Alcuni strumenti di product management permettono di avere sia la definizione di fatto sia i criteri di accettazione sulle tue storie.
Ora che ricordiamo cosa sono epiche e storie, e come i criteri di accettazione sono collegati a esse, passiamo a capire perché i product owner scrivono i criteri di accettazione.
Qual è lo scopo di scrivere i criteri di accettazione?
Posso semplicemente scrivere la descrizione di una user story come voglio senza includere alcun criterio di accettazione? Qual è il vantaggio di scrivere i criteri di accettazione?
Certo, puoi scrivere le tue storie come preferisci. Tuttavia, ti consiglio di utilizzare i criteri di accettazione come modo per formulare i tuoi requisiti, poiché questo formato offre numerosi vantaggi. Eccone alcuni da considerare.
Favoriscono un pensiero orientato al comportamento
Se opti per il formato BDD dei criteri di accettazione (ne parleremo più avanti), i criteri di accettazione descriveranno il percorso dei tuoi clienti quando utilizzano la funzionalità in questione.
La bellezza di questo approccio è che si sposta l'attenzione dai freddi requisiti tecnici e si comincia a guardare alla funzionalità dal punto di vista dell'utente. In questo modo, sei in grado di visualizzare ciò che provano ed esperiscono quando interagiscono con la tua funzionalità.
È molto comune che il product owner si renda conto che la funzionalità immaginata non è la migliore una volta che la osserva dal punto di vista degli utenti.
Mi è capitato diverse volte. Ad esempio, quando stavo creando i requisiti per un editor di formule matematiche (era parte di un prodotto SaaS per analisi finanziaria che stavamo sviluppando all'epoca), volevo che il processo di modifica funzionasse così:
- Un pulsante Modifica accanto alla formula.
- Cliccando sul pulsante Modifica, il campo formula diventava modificabile e comparivano i pulsanti ✅ Salva e ❎ Annulla .
- Cliccando su uno dei due si usciva dalla modalità di modifica e compariva la nuova versione salvata oppure la vecchia versione della formula, a seconda della selezione dell'utente.
Questo comportamento sembra logico, giusto?
Beh, non fino a quando non ho iniziato a scrivere scenari di utilizzo per gli analisti e ho riscontrato un notevole difetto di usabilità. Gli analisti spesso smanettano con la formula apportando piccole modifiche e osservando il risultato del calcolo fino a ottenere la formula desiderata.
Il modo in cui avevo immaginato la modifica sarebbe stato estremamente fastidioso per i miei utenti target, poiché avrebbero dovuto entrare e uscire dalla modalità modifica per 20-30 volte di seguito. Appena mi sono reso conto dell'errore, ho aggiornato velocemente i criteri di accettazione e richiesto la realizzazione di un editor di formule che permettesse modifiche in tempo reale.
Aiutano a creare un'unica fonte di verità
Come giovane product manager, la mia maggiore difficoltà era comunicare i requisiti di prodotto a persone di professioni o di team diversi. Il problema era che ognuno li interpretava in modo differente e la comunicazione diventava confusa.
Fu allora che un product manager esperto mi suggerì di applicare il concetto di unica fonte di verità, formulando i miei requisiti in modo chiarissimo (questa è una cosa in cui l'IA nella raccolta dei requisiti può aiutare), comunicandoli a tutti e chiedendo di basare il lavoro solo su ciò che era scritto lì.
Fu un grande successo, perché tutti avevano la stessa comprensione di come doveva funzionare la funzionalità e, in caso di disaccordi, si faceva riferimento al requisito scritto.
I criteri di accettazione sono un ottimo modo per creare un'unica fonte di verità poiché descrivono la funzionalità in maniera chiara, di facile lettura e con un alto livello di dettaglio (in quanto dovrebbero coprire tutti i principali dettagli della funzionalità).
Migliorano la Qualità dei Test di Accettazione
Per gli ingegneri software, i criteri di accettazione rappresentano i requisiti di prodotto che seguiranno nello sviluppo della funzionalità. Per il tuo team qualità, invece, i criteri di accettazione hanno alcune caratteristiche aggiuntive:
Aiutano a prioritizzare i casi di test. Se il tuo team di testing ha molti casi di test per quella funzionalità e non c’è abbastanza tempo per esaminarli tutti, daranno la priorità e eseguiranno prima gli scenari di test che corrispondono ai criteri di accettazione, in quanto descrivono i flussi utente più critici.
Servono come checklist di accettazione. Questo punto vale sia per i team QA che per i product owner che devono accettare la funzionalità. I criteri di accettazione, come dice il nome stesso, fungono da checklist per determinare l’esito positivo o negativo della funzionalità. Se uno o più criteri di accettazione non vengono soddisfatti, il team QA riaprirà la storia chiedendo al team di sviluppo di aggiungere la funzionalità mancante.
In sintesi, i criteri di accettazione sono strumenti preziosissimi nelle mani dei product owner per comunicare correttamente i requisiti di prodotto. Ma come si scrivono dei buoni criteri di accettazione? Lascia che ti aiuti a capirlo nel prossimo paragrafo.
Come dovrebbero essere scritti dei buoni criteri di accettazione?
La qualità dei criteri di accettazione che scrivi avrà un impatto diretto sulla qualità delle funzionalità che il tuo team andrà a realizzare. Con una chiara comprensione di cosa costruire e di come testarlo, il team realizzerà la funzionalità come l’avevi immaginata, con il minimo degli intoppi.
Per eccellere nella scrittura dei criteri di accettazione, dovrai prestare attenzione ai seguenti aspetti.
Chiarezza
Il peccato numero uno che un product owner possa commettere è scrivere criteri di accettazione poco chiari e vaghi. Puoi scordarti la nozione di comprensione condivisa se le persone possono interpretare ciò che hai scritto in più modi diversi.
Per capire davvero quanto faccia la differenza, lascia che ti mostri un esempio.
Cosa hai capito da questa frase? Riesci a dirmi in che modo il bancomat utilizzerà il tipo di carta per decidere se autenticare o meno l’utente? Il bancomat autenticherà l’utente solo se tutti questi criteri sono soddisfatti contemporaneamente o basta che ne venga soddisfatto anche solo uno?
Se dai questo criterio di accettazione ai tuoi ingegneri, ti sommergeranno di domande e ti chiederanno di essere più chiaro nei requisiti. Ora miglioriamolo.
Decisamente meglio, vero? Con questo criterio di accettazione abbiamo fornito anche le risposte a tutte le domande sopra. Il bancomat deve supportare il tipo di carta inserito dall’utente e tutti e tre i criteri devono essere soddisfatti contemporaneamente affinché il bancomat proceda con l’autenticazione.
Consiglio Pro: Rendi i tuoi criteri di accettazione SMART (specifici, misurabili, raggiungibili, rilevanti, testabili). Sì, ho cambiato l’ultimo in "testabili", perché è una caratteristica importante di criteri di accettazione efficaci.
Leggibilità
Oltre a evitare vaghezza nei tuoi criteri di accettazione, dovresti anche mantenerli semplici ed evitare termini ricercati o inglese troppo complesso.
Sono sicuro che hai un team di superstar altamente istruiti che possono leggere e capire facilmente anche le parole e frasi più complesse della lingua inglese, ma non vuoi davvero sprecare la loro energia cognitiva a decifrare i tuoi testi.
Quindi, invece di questo.
Dì questo.
Immagino che non ti sia nemmeno preso la briga di leggere tutto il primo criterio di accettazione perché probabilmente non volevi perdere tempo e fatica mentale!
Copertura dei Casi
Il diavolo si nasconde nei dettagli. A volte ti accorgi di aver tralasciato un caso spiacevole nella tua funzionalità quando ormai sei molto avanti nella fase di sviluppo e sei costretto ad aprire un'attività di miglioramento successiva o addirittura a rifare tutto da capo.
Sembra familiare, vero?
Più casi prendi in considerazione nei criteri di accettazione fin dall'inizio, minore sarà la possibilità di incontrare quello scenario con gli elementi nel tuo backlog.
Ora, diamo un'occhiata ai criteri di accettazione qui sotto.
Noti qualcosa di strano qui? A prima vista, la richiesta è chiara: aggiungi l'indirizzo email, premi invia e la persona ottiene l'accesso. In realtà, ci sono molti casi che non abbiamo considerato qui:
- Se l'indirizzo email è già presente nell'elenco degli utenti che hanno accesso al documento, forse dovresti mostrare un messaggio di errore che lo segnala all'utente.
- Invierai un'email di invito all'utente, quindi potrebbe valere la pena mostrare se ha accettato o meno l'invito nella lista condivisione.
- Se non hanno accettato l'invito, forse è utile aggiungere un pulsante "invia nuovamente invito".
Ci sono anche casi negativi in cui chiarisci il comportamento della tua funzionalità quando qualcosa è vuoto o si è verificato un errore.
Uso Attivo di Supporti Visivi
I criteri di accettazione che ho condiviso sopra ti sono stati completamente chiari? Quando ho parlato del campo “Aggiungi persone e gruppi”, hai capito chiaramente di cosa si trattava?
A volte le parole non bastano per portare chiarezza sui requisiti al tuo team; in questi casi è meglio mostrare piuttosto che raccontare. Ora, lascia che migliori un po' questi criteri di accettazione.
Posso supporre che avresti capito facilmente di cosa stavo parlando con questi criteri di accettazione se avessi visto l'immagine e i miei commenti fianco a fianco? Scommetto di sì.
Questo conclude i "criteri di accettazione" dei criteri di accettazione—ora parliamo dei diversi tipi e formati utilizzati dai team di prodotto.
Formati Comuni dei Criteri di Accettazione
Devo essere sincero con te. Raramente utilizzo lo stesso formato in tutte le mie user story. Il motivo è che diversi formati di criteri di accettazione sono ottimi per casi d’uso differenti e non è sempre la scelta migliore imporsi di usare sempre lo stesso formato.
Quindi, scelgo il formato basandomi sulla storia e sul tipo di informazione che voglio scrivere nei relativi criteri di accettazione.
Vediamo ora alcuni dei formati più comuni e i relativi esempi di criteri di accettazione.
Formato BDD
BDD sta per Behavior-driven Development ed è un framework che incoraggia gli sviluppatori e i team di prodotto a definire i requisiti in base al modo in cui gli utenti finali interagiranno con la funzionalità.
Come metodo per scrivere requisiti basati sul comportamento degli utenti, i criteri di accettazione BDD seguono questo specifico schema:
Dato: La precondizione per lo scenario specifico del comportamento dell’utente.
Quando: L’azione che l’utente compie.
Allora: Il risultato dell’azione.
Quindi, se volessi spiegare come funziona la funzionalità di prelievo di un bancomat, i tuoi criteri di accettazione sarebbero così:
Il tipo di criteri di accettazione dato/quando/allora è ottimo quando vuoi creare empatia verso i bisogni dell'utente all’interno del team, mettendo l'accento sulla prospettiva dell’utente.
Formato Checklist
A differenza del BDD (noto anche come formato “orientato allo scenario”), questo non mostra il punto di vista dell’utente finale. Invece, si tratta di spiegare le regole che la logica di business della funzionalità deve seguire (nome alternativo di questo formato è “orientato alle regole”). Ecco come si presentano.
Questo formato è il più adatto quando la logica che vuoi spiegare è complessa, perché ti aiuta a suddividerla in più piccole regole più facili da comprendere e implementare.
Formato Flusso
Probabilmente questo è il formato che utilizzo di più.
Il formato flow è simile al formato BDD in quanto mostra anche il punto di vista dell’utente. Tuttavia, a differenza della BDD, non impone una struttura rigida (Given/When/Then). Quindi, sei libero di narrare i passaggi che l’utente compie come preferisci.
Ecco come apparirebbe il processo di registrazione con questo formato.
Il formato flow sarà la scelta migliore se vuoi creare empatia con l’utente (proprio come con la BDD) ma non vuoi davvero seguire una struttura rigida.
Mantieni tutti allineati con i criteri di accettazione
I criteri di accettazione sono strumenti potenti nelle mani dei product owner, permettendo loro di creare una singola fonte di verità e mantenere i membri del team allineati alla loro visione per quella funzionalità.
Per altre guide come questa e altre risorse utili per chi lavora nel prodotto, iscriviti alla nostra newsletter!
