Guida Scrum | 19. Storie degli utenti: cosa sono?

La User Story è una breve descrizione di una nuova funzionalità del Prodotto o del suo miglioramento. Non contiene una soluzione tecnica ma risponde a domande riguardanti la funzionalità: chi è l'utente? Cosa fa il Prodotto? E qual è il suo scopo? La User Story descrive il prodotto nel linguaggio quotidiano o lavorativo, sebbene indichi anche i compiti dello Scrum Team che hanno lo scopo di migliorare le prestazioni del Team.

Cosa sono le User Story? - sommario:

1. introduzione
2. Storia dell'utente. Di chi è la storia?
3. Come utilizzare le storie degli utenti?
4. Criteri di accettazione
5. Riepilogo

introduzione

La User Story è il modo più comune per formulare i compiti svolti dallo Scrum Team. Una singola User Story definisce una piccola funzionalità del Prodotto. Descrive il più piccolo obiettivo di prodotto significativo e parziale. Per questo motivo, le User Story sono molto brevi.

Le User Story vengono create durante tutto il tempo in cui si lavora sul Prodotto. Vengono creati continuamente, dal momento in cui viene presa la decisione di iniziare il lavoro, fino alla realizzazione dell'Obiettivo del Prodotto.

La creazione di storie utente è un'attività del Product Owner. Sulla base di una conversazione con un Cliente, formula le risposte alle domande che consentono di creare User Story e le inserisce nel Product Backlog. Tuttavia, le User Story non riflettono solo le esigenze dei clienti.

Storia dell'utente. Di chi è la storia?

Lo Scrum Team crea una User Story per definire le esigenze dell'Utente, ed è per questo che è scritta in linguaggio commerciale. In altre parole, indica i vantaggi che la sua implementazione porterà all'utente del prodotto. Tuttavia, nel Product Backlog possono esserci anche User Story che descrivono le esigenze del Team di Sviluppo, ad esempio migliorando il flusso di lavoro tra gli Sviluppatori, o descrivono le esigenze del Product Owner, ad esempio organizzando il Product Backlog. In questi casi, l'Utente nella User Story è lo Sviluppatore e il Product Owner.

Puoi descrivere una User Story rispondendo alle domande 3W :

• Chi?
• sta facendo cosa?
• Come mai?

La User Story è quindi contenuta in una formula:

Come [tipo di utente], voglio [fare cosa?] Perché [perché? perché?].

Esempi di User Story sulla funzionalità di un negozio online scritti in questo modulo sono illustrati nella tabella seguente:

Questa formula permette non solo di formulare una User Story ma anche di tradurre con relativa facilità il linguaggio tecnico in business e viceversa . Di conseguenza, sia gli sviluppatori che gli stakeholder vedono chiaramente l'obiettivo e le fasi del suo progresso. Tratteremo anche la creazione di buone User Story usando il metodo INVEST in un articolo separato della serie Scrum Guide.

Come utilizzare le storie degli utenti?

La creazione di una User Story schematica è solo l'inizio. Sono segnali e punti di partenza per discussioni sui problemi e le loro soluzioni. La discussione sulle storie degli utenti avviene durante lo Sprint Planning per risolvere quali problemi tecnici il team di sviluppo aggiungerà allo Sprint Backlog.

Tipicamente, nello spazio fisico, le User Story sono scritte su piccole schede colorate appuntate sul posto di lavoro. Tuttavia, nello spazio digitale, le lavagne digitali, condivise dallo Scrum Team, funzionano meglio.

Salvare le User Story in questo modo ha diversi vantaggi perché:

• Sottolinea l'autonomia di ciascuna User Story : ognuna ha una struttura separata e può essere eseguita indipendentemente dalle altre
• Enfatizza la dinamica delle User Story – l'ordine della loro realizzazione viene rinegoziato dallo Scrum Team e l'attuale ordine di realizzazione è visibile sul board grazie alla disposizione fisica delle carte con le User Story
• Serve come promemoria : grazie alla rappresentazione visiva delle User Story, lo Scrum Team ha un cartello in vista per ricordare loro l'obiettivo durante la creazione di soluzioni dettagliate.

Il Team di sviluppo stima lo sforzo richiesto per completare una User Story con giorni, ore uomo o Story Point.

Criteri di accettazione

Una User Story deve avere determinati criteri di accettazione nel momento stesso in cui viene accettata per lo sviluppo dal Team di Sviluppo. I criteri di accettazione determinano a che punto il lavoro su una User Story può essere considerato terminato.

In questo modo sia il cliente che gli sviluppatori sanno come il loro lavoro si tradurrà in valore aziendale. In genere, una User Story è considerata completata quando l'utente in essa specificato può eseguire l'azione descritta. Utilizzando l'esempio sopra, dai un'occhiata a questa User Story con il contenuto:

Un cliente può acquistare una bacchetta magica con un solo clic.

Viene completato quando nella pagina del negozio online viene visualizzato un pulsante "Acquista ora" funzionante , che utilizza le informazioni di pagamento e spedizione predefinite per l'utente che ha effettuato l'accesso.

Riepilogo

Una User Story è una descrizione concisa di una nuova funzionalità o miglioramento del Prodotto. Serve come il più piccolo obiettivo espresso nel linguaggio commerciale, cioè dal punto di vista del valore aziendale e dell'utente. Aiuta a definire chiaramente il compito da svolgere e i criteri per il suo completamento.

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