Categories: BlogGuida Scrum

Guida Scrum | 22. Criteri di Accettazione delle User Story

La User Story è una tecnica che consente alle aziende di fornire prodotti e servizi che soddisfano al massimo le esigenze dei clienti. I criteri di accettazione della User Story migliorano la valutazione delle nuove funzionalità del prodotto dal punto di vista dell’utente.

Criteri di Accettazione della User Story – indice:

  1. Introduzione
  2. Come formulare i Criteri di Accettazione della User Story?
  3. Criteri di Accettazione della User Story vs. Definizione di Fatto
  4. Riepilogo

Introduzione

Abbiamo trattato la User Story e le questioni da affrontare durante la sua creazione in articoli precedenti. Oggi, tuttavia, ci concentreremo sui criteri di accettazione della User Story.

I criteri di accettazione dovrebbero seguire queste linee guida:

  • descrivere la nuova e migliorata funzionalità del prodotto dal punto di vista dell’utente
  • essere unici per ogni User Story

La Guida Scrum ufficiale non definisce la User Story e i suoi criteri di accettazione. Essi sono elementi opzionali, ma molto comuni nel lavoro Scrum. Tuttavia, per soddisfare la curiosità dei nostri lettori, li descriveremo come: Le condizioni che un miglioramento del prodotto deve soddisfare durante uno Sprint dato per ottenere l’approvazione dell’utente.

Come formulare i Criteri di Accettazione della User Story?

Una User Story ben scritta contiene una chiara descrizione del contesto o della situazione a cui si riferisce, soddisfacendo così i criteri di accettazione. Tuttavia, è solo una frase breve, troppo vaga e ambigua per individuare direttamente le considerazioni necessarie.

Chiarezza e accessibilità dei criteri di accettazione

Pertanto, per prevenire ambiguità, conduci e registra una conversazione dettagliata con il cliente per determinare lo scopo della soluzione implementata. Ricorda che la formulazione finale dei criteri di accettazione spetta al Product Owner.

Scrivili insieme ai criteri della User Story prima della Pianificazione dello Sprint. Ogni membro del Team Scrum deve leggerli e confermare di comprendere e concordare con i criteri di accettazione della User Story. Di solito, i criteri di accettazione si trovano dal lato opposto della scheda della User Story.

I criteri di accettazione formulati correttamente consentono all’utente di verificare se il test della User Story segue la sua descrizione. I criteri possono assumere la forma di una lista di controllo con punti elenco da spuntare quando completati durante il test del prodotto alla fine di uno Sprint.

La questione è semplice se il funzionamento del prodotto è trasparente per l’utente. Tuttavia, più complesso è il prodotto, più difficile diventa testarlo. Prendi in considerazione software complessi o servizi su larga scala. Pertanto, nella maggior parte dei casi, uno strumento utile per convalidare la User Story è preparare un test di accettazione.

Test di accettazione

Se decidi di sviluppare un test di accettazione, annotalo sul lato opposto della scheda contenente la User Story. Successivamente, il Team Scrum o un team QA esterno possono eseguirlo.

Il test deve contenere prima di tutto una chiara dichiarazione su se il prodotto fallisce o supera il test. Non può contenere dichiarazioni percentuali o valutazioni intermedie.

Se la User Story ha più di un criterio di accettazione, ciascuno richiede test separati. In questo modo, è molto più facile determinare quale funzionalità del prodotto necessita di miglioramenti o affinamenti ed è particolarmente importante se le nuove funzionalità incluse nella User Story si sovrappongono o sono indipendenti l’una dall’altra.

Criteri di Accettazione della User Story vs. Definizione di Fatto

La Definizione di Fatto è una parte integrante del lavoro in Scrum, che è l’equivalente tecnico dei criteri di accettazione. Tuttavia, non dovresti confondere questi due poiché denotano impegni diversi. Cos’è la Definizione di Fatto, e come e quando formularla è un argomento che abbiamo trattato in un post separato?

Qui, menzioneremo solo che la Definizione di Fatto è una chiara e trasparente descrizione dello stato atteso del prodotto dopo il completamento dell’Incremento nel Product Backlog. Descrive i miglioramenti apportati all’interno dell’Incremento. Questo sta in contrasto con il criterio di accettazione corrispondente alla User Story, che descrive la funzionalità del prodotto creata durante l’ultimo Sprint come percepita dal cliente.

Ad esempio, prendi questa User Story con il contenuto:

Come cliente registrato di un negozio online, voglio acquistare una bacchetta magica con un clic.

La Definizione di Completamento per la sopra citata User Story potrebbe includere i seguenti elementi:

  • la creazione di un pannello di accesso per i clienti del negozio
  • integrazione del sistema di pagamento
  • aggiunta del pulsante di pagamento istantaneo al modello della pagina del prodotto

D’altra parte, i criteri di accettazione del cliente includono:

  • la possibilità di accedere al negozio
  • la possibilità di definire un metodo di pagamento predefinito
  • funzionante pulsante “Acquista ora” per il prodotto “bacchetta magica”

Riepilogo

I criteri di accettazione sono un insieme di condizioni che funzionano come un modo per valutare l’implementazione della User Story. Descrivendo le nuove e migliorate prestazioni del prodotto dal punto di vista dell’utente, questo metodo diventa uno strumento efficace per lavorare con il cliente. Presenta le prestazioni del Team Scrum dal punto di vista dell’utente.

Criteri di accettazione ben formulati, ad esempio sotto forma di un test di accettazione, ci consentono anche di verificare durante uno Sprint se la funzionalità creata migliora la soddisfazione delle esigenze del cliente.

I criteri di accettazione si differenziano dalla Definizione di Fatto principalmente nella prospettiva che assumono nell’espressione. Non contengono una descrizione dei requisiti tecnici che la nuova soluzione dovrebbe soddisfare, ma solo le funzioni che il prodotto dovrebbe presentare dopo l’attuazione della nuova User Story.

Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Caroline Becker

Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.

View all posts →

Caroline Becker

Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.

Share
Published by
Caroline Becker

Recent Posts

Guida Scrum | 28. Sprint in Scrum

Diverse eventi più piccoli compongono uno Sprint in Scrum. Gli Sprint, a loro volta, formano…

1 hour ago

Come attirare più clienti nella tua attività con il video marketing?

I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…

3 hours ago

Come trovare un copywriter?

La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…

4 hours ago

Perché hai bisogno di un’app per il time blocking? Le 8 migliori app del 2023

Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…

6 hours ago

Che cos’è il software? Tipi e metodi di distribuzione – Crea e vendi prodotti digitali #34

Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…

7 hours ago

Come preparare un rapporto di ricerca UX? | Ricerca UX #34

Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…

9 hours ago