Guida Scrum | 22. Criteri di accettazione della User Story

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 – sommario:

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 i problemi da affrontare al momento della sua creazione negli articoli precedenti. Oggi, invece, ci concentreremo sui criteri di accettazione delle 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 unico per ogni User Story

La Guida Scrum ufficiale non definisce la User Story e i suoi criteri di accettazione. Sono elementi opzionali, ma molto comuni del lavoro di Scrum. Tuttavia, per facilitare la curiosità dei nostri lettori, li descriveremo come: Le condizioni che un miglioramento del Prodotto deve soddisfare durante un determinato Sprint 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 che interessa, 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à, condurre e registrare una conversazione dettagliata con il cliente per determinare lo scopo della soluzione implementata. Si ricorda che la formulazione finale dei criteri di accettazione spetta al Product Owner.

Annotali insieme ai criteri della User Story prima di Sprint Planning. Ogni membro dello Scrum Team deve leggerlo e confermare di aver compreso e concordato con i criteri di accettazione della User Story. Di solito, i criteri di accettazione sono sull'altro lato della scheda User Story.

Criteri di accettazione opportunamente formulati consentono all'utente di verificare se il test della User Story segue la sua descrizione. I criteri possono assumere la forma di una checklist con punti elenco da spuntare una volta completati durante il test del prodotto al termine di uno Sprint.

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

Test d'ingresso

Se decidi di sviluppare un test di accettazione, mettilo sull'altro lato della scheda contenente la User Story. Successivamente, lo Scrum Team o un QA team esterno possono eseguirlo.

Il test deve innanzitutto contenere una chiara indicazione se il Prodotto non supera 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 un test separato. In questo modo, è molto più facile determinare quale funzionalità del prodotto necessita di miglioramento o perfezionamento 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 è parte integrante del lavoro in Scrum, che è l'equivalente tecnico dei criteri di accettazione. Tuttavia, non dovresti confondere questi due poiché denotano impegni diversi. Qual è la definizione di fatto e come e quando formularla è un problema che abbiamo trattato in un post separato?

Qui, menzioneremo solo che la Definizione di Fatto è una descrizione chiara e trasparente dello stato atteso del Prodotto dopo il completamento dell'Incremento nel Product Backlog. Descrive i miglioramenti apportati all'interno dell'Incremento. Ciò contrasta con il criterio di accettazione corrispondente alla User Story, che descrive la funzionalità del Prodotto creata durante l'ultimo Sprint così come viene 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 User Story di cui sopra potrebbe includere quanto segue:

• la creazione di un pannello di login per i clienti del punto vendita
• integrazione del sistema di pagamento
• aggiungendo il pulsante di pagamento istantaneo al modello di pagina del prodotto

I criteri di accettazione da parte del cliente, invece, prevedono:

• la possibilità di accedere al negozio
• la possibilità di definire una modalità di pagamento di default
• pulsante “Acquista ora” funzionante 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 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 dello Scrum Team 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 richieste del Cliente.

I criteri di accettazione differiscono dalla definizione di fatto principalmente nella prospettiva che assumono sull'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'attualizzazione della nuova User Story.

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog