Come scrivere criteri di accettazione in Jira, con esempi pratici

«I clienti possono modificare le preferenze di notifica» sembra un ticket Jira chiaro finché qualcuno non inizia a implementarlo. Una modifica viene salvata subito? Cosa succede se il salvataggio fallisce? La preferenza sarà ancora presente domani? Quali email sono interessate?

I criteri di accettazione trasformano queste domande aperte in risultati concordati e osservabili. Aiutano chi richiede, realizza e revisiona una modifica a lavorare con le stesse aspettative.

In questa guida svilupperemo i criteri per una funzionalità immaginaria di un portale clienti, miglioreremo requisiti vaghi e aggiungeremo una checklist pratica a Definition of Done & AC di Power Pack. Non serve un formato di scrittura speciale per iniziare. Bastano condizioni e risultati chiari.

Che cosa sono i criteri di accettazione?

I criteri di accettazione descrivono le condizioni che un’attività specifica deve soddisfare per essere accettata. Si concentrano sul risultato atteso di quell’elemento. Atlassian li distingue dalla Definition of Done, che descrive lo standard di qualità più ampio per il lavoro completato. Consulta la guida ai criteri di accettazione di Atlassian.

Nel nostro esempio, «Una scelta di notifica salvata resta selezionata quando il cliente accede di nuovo» è un criterio di accettazione. «L’implementazione è stata revisionata» appartiene alla Definition of Done condivisa.

Questa distinzione mantiene utile ogni lista. I criteri di accettazione spiegano se la funzionalità fa ciò che il team ha concordato. La Definition of Done spiega se il lavoro soddisfa lo standard di completamento più ampio del team.

Nessuna delle due liste deve contenere ogni passaggio implementativo. «Creare un campo nel database» può essere un’attività tecnica necessaria, ma non dice a un cliente o revisore se la preferenza si comporta correttamente.

Parti da un risultato per il cliente

Il nostro ticket immaginario si chiama «Consentire ai clienti di controllare l’email di riepilogo settimanale». Il risultato previsto è che un cliente autenticato possa scegliere se ricevere un riepilogo settimanale senza modificare i messaggi essenziali dell’account.

Prima di scrivere i criteri, il team concorda alcune decisioni di ambito. L’impostazione ha un pulsante Save esplicito. Il cliente modifica soltanto la propria preferenza. La preferenza riguarda i riepiloghi non ancora messi in coda. I messaggi già in coda sono esclusi dalla regola di consegna di questo ticket.

Questi dettagli sono inventati per l’esempio. Il tuo team dovrebbe decidere il comportamento effettivo anziché copiarli come requisiti di prodotto.

Una breve nota sull’ambito può evitare che una checklist lunga debba contenere tutto il contesto. Nella descrizione Jira, il team registra che il ticket riguarda una preferenza nella pagina delle impostazioni dell’account. Scegliere i giorni di consegna, cambiare gli indirizzi email e gestire le preferenze di altri clienti sono attività separate.

Ora i criteri possono concentrarsi sui risultati che stabiliscono se questa specifica modifica funziona.

Scrivi prima il percorso normale

Parti dall’esperienza che prevedi seguirà la maggior parte dei clienti. Esprimi condizione iniziale, azione e risultato osservabile in linguaggio comune.

Per esempio: «Quando un cliente autenticato disattiva i riepiloghi settimanali e salva correttamente, riaprendo le impostazioni dell’account i riepiloghi risultano disattivati». Un revisore può creare lo stato iniziale, eseguire l’azione e controllare il risultato.

Questa frase è più utile di «Le preferenze vengono salvate correttamente». Specifica quale preferenza cambia, quando la modifica ha effetto e come verificarla.

Il team necessita anche della direzione opposta. Un controllo che disattiva correttamente i riepiloghi ma non riesce ad attivarli è incompleto. Scrivi un criterio separato quando il comportamento inverso merita una verifica propria.

Non forzare risultati non correlati in una sola voce. Salvataggio, uso da tastiera, consegna delle email e gestione degli errori possono essere tutti importanti, ma un criterio enorme rende difficile mostrare quale parte necessita ancora di attenzione.

Aggiungi casi di errore e di confine

Il percorso normale presume che il salvataggio riesca. Chiedi che cosa dovrebbe vedere il cliente quando questo presupposto è falso.

Il nostro team sceglie questa regola: se la richiesta di salvataggio fallisce, la pagina mostra un errore e non mostra una conferma di successo. Riaprendo la pagina, resta la preferenza salvata in precedenza. Questo fornisce al revisore un caso di errore concreto da esercitare nell’ambiente di test del team.

Esamina poi il confine della funzionalità. L’impostazione del riepilogo settimanale non deve impedire un’email di ripristino della password. La scelta del cliente deve inoltre sopravvivere a una nuova sessione di accesso. Sono aspetti diversi e ricevono criteri separati.

Evita di scrivere «Tutti i casi limite sono gestiti». Nomina i casi importanti. Una discussione utile spesso parte da tre domande: cosa potrebbe fallire, cosa deve restare invariato e cosa succede in seguito?

Se il team non riesce a concordare un risultato atteso, registra la decisione irrisolta prima che l’implementazione avanzi troppo. Una domanda senza risposta non diventa un criterio utilizzabile soltanto perché è stata inserita in una checklist.

Una checklist completa di criteri di accettazione

Ecco la prima bozza completa per il ticket immaginario. Ogni voce descrive un risultato che il team può verificare separatamente.

• L’apertura delle impostazioni dell’account mostra la preferenza di riepilogo settimanale attualmente salvata dal cliente.
• Dopo aver disattivato i riepiloghi settimanali e salvato correttamente, riaprendo le impostazioni dell’account la preferenza risulta disattivata.
• Dopo aver attivato i riepiloghi settimanali e salvato correttamente, riaprendo le impostazioni dell’account la preferenza risulta attivata.
• Dopo un salvataggio riuscito, uscire e accedere nuovamente mantiene la preferenza salvata.
• Se il salvataggio fallisce, viene mostrato un errore, non compare una conferma di successo e riaprendo le impostazioni appare la preferenza salvata in precedenza.
• Un cliente con la preferenza disattivata non riceve alcun riepilogo settimanale messo in coda dopo il salvataggio riuscito.
• Un cliente con la preferenza attivata resta idoneo al prossimo riepilogo settimanale secondo le regole di pianificazione esistenti.
• Disattivare i riepiloghi settimanali non impedisce a quel cliente di ricevere un’email richiesta per ripristinare la password.

Le voci relative alla consegna dipendono dalla decisione di ambito sui messaggi in coda. Il team registra quel contesto accanto al ticket, affinché il revisore non presuma che l’impostazione richiami email già in fase di invio.

Questi criteri richiedono anche un approccio di verifica praticabile. Per il comportamento di consegna, il team identifica come attivare o osservare un riepilogo nell’ambiente di test. Un criterio può essere scritto chiaramente ma difficile da verificare se nessuno ha accesso all’account o alle prove di consegna necessari.

Migliora i criteri vaghi prima di aggiungerli

Una rapida revisione delle parole spesso evita disaccordi più lunghi in seguito. Leggi ogni voce e chiedi se due persone potrebbero interpretare il successo in modi diversi.

L’ultimo esempio da solo non dimostra l’usabilità. Sostituisce una frase vaga con un controllo utile e limitato. Obiettivi di usabilità più ampi possono richiedere ricerca o diverse osservazioni concordate.

Fai attenzione anche alla precisione inventata. Aggiungere un requisito di risposta in due secondi sembra misurabile, ma crea un impegno reale. Concorda le condizioni e il motivo di una soglia prestazionale prima di includerla.

Inserisci i criteri in Power Pack

Apri il ticket Jira e trova la scheda Definition of Done & AC. Seleziona Acceptance Criteria. La sua lista è separata dalla scheda Definition of Done, quindi controlla la scheda selezionata prima di inserire contenuti.

Per aggiungere un criterio, scrivi il titolo e seleziona Add oppure premi Invio. Usa titoli concisi che conservino comunque il risultato atteso. Se un criterio richiede molto contesto, mantienilo nella descrizione Jira o nella documentazione collegata del team.

Per diverse voci, seleziona Bulk Import e incolla un elenco puntato Markdown. Puoi copiare le voci dell’esempio precedente inserendo un trattino e uno spazio prima di ciascuna. Sono supportati anche elenchi Markdown con caselle di controllo.

Esamina le voci risultanti dopo l’importazione. L’azione aggiunge elementi alla lista corrente, quindi importare di nuovo la stessa checklist può creare voci già presenti. Le caselle Markdown selezionate arrivano segnate come completate: inizia con voci non selezionate, a meno che i risultati del ticket attuale siano stati davvero verificati.

Se una voce è sbagliata, esamina con il team la formulazione sostitutiva, aggiungi quella corretta ed elimina quella obsoleta tramite la richiesta di conferma. Mantieni chiara la discussione di supporto nel ticket quando una modifica influisce sull’ambito concordato.

Verifica i risultati prima di segnarli come completati

Prima dell’implementazione, chiedi a qualcuno coinvolto nella verifica di ripercorrere i criteri proposti. Potrebbe notare condizioni iniziali mancanti o un risultato non osservabile con la configurazione di test disponibile.

Dopo l’implementazione, verifica ogni risultato e registra le prove tramite il normale processo Jira o documentale del team. Seleziona Done quando il risultato concordato è stato verificato positivamente. Selezionarlo di nuovo riporta la voce da fare se una scoperta successiva riapre il controllo.

Per esempio, la preferenza potrebbe sopravvivere al ricaricamento della pagina ma azzerarsi dopo un nuovo accesso. Il criterio di riapertura della pagina può essere superato mentre quello di persistenza della sessione resta incompleto. Le voci separate conservano questa distinzione utile.

Power Pack monitora il completamento della checklist; non esegue i test né stabilisce automaticamente chi li ha revisionati. Se la revisione richiede una verifica nominativa o un risultato datato, registra questi dettagli esplicitamente nel processo abituale.

Usa entrambi i conteggi senza confonderli con prove

Acceptance Criteria e Definition of Done mostrano ciascuno i propri conteggi di voci completate e totali. L’indicatore di preparazione mostra Ready for Release solo quando entrambe le liste non sono vuote e tutte le voci sono completate. Altrimenti mostra In Verification.

Questo è un riepilogo dello stato della checklist inserita. Non può stabilire che i criteri coprano ogni comportamento importante o che le prove di supporto siano solide. Non impone inoltre transizioni del flusso Jira né blocca le integrazioni del codice.

Il nostro ticket delle notifiche potrebbe avere tutti gli otto criteri di accettazione completi mentre le indicazioni per l’assistenza restano incomplete in Definition of Done. I risultati della funzionalità sono stati verificati, ma l’accordo più ampio di completamento del team ha ancora una voce aperta.

Parti da un ticket Jira imminente. Scrivi il risultato per il cliente, concorda le condizioni e i risultati importanti, poi aggiungi i criteri in Power Pack accanto alla Definition of Done condivisa. Esamina la lista con chi realizzerà e verificherà la modifica. Il vantaggio è avere meno supposizioni nascoste dietro una frase che inizialmente sembrava ovvia.

• Atlassian — Che cosa sono i criteri di accettazione?