Guida Scrum | 19. Storie Utente – cosa sono?

La User Story è una breve descrizione di una nuova funzionalità del Prodotto o del suo miglioramento. Non contiene una soluzione tecnica ma affronta domande riguardanti la funzionalità: Chi è l’utente? Cosa fa il Prodotto? E qual è il suo scopo? La User Story descrive il prodotto in linguaggio quotidiano o aziendale, sebbene indichi anche i compiti del Team Scrum che sono destinati a migliorare le prestazioni del Team.

Che cosa sono le User Stories? – indice:

1. Introduzione
2. User Story. Di chi è la storia?
3. Come utilizzare le User Stories?
4. Criteri di Accettazione
5. Riepilogo

Introduzione

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

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

Creare User Stories è un compito del Product Owner. Basandosi su una conversazione con un Cliente, formula risposte a domande che consentono di creare la User Story e le inserisce nel Product Backlog. Tuttavia, le User Stories riflettono non solo le esigenze del cliente.

User Story. Di chi è la storia?

Il Team Scrum crea una User Story per definire le esigenze dell’Utente, e per questo motivo è redatta in linguaggio aziendale. In altre parole, indica i benefici che la sua implementazione porterà all’utente del prodotto. Tuttavia, nel Product Backlog, possono esserci anche User Stories che descrivono le esigenze del Team di Sviluppo, ad esempio migliorare il flusso di lavoro tra gli Sviluppatori, o descrivere le esigenze del Product Owner, ad esempio organizzare il Product Backlog. In tali 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?
• Perché?

La User Story è quindi contenuta in una formula:

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

Esempi di User Stories riguardanti la funzionalità di un negozio online scritti in questa forma sono illustrati nella tabella sottostante:

Questa formula consente non solo di formulare una User Story ma anche di tradurre relativamente facilmente il linguaggio tecnico in linguaggio aziendale 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 Stories utilizzando il metodo INVEST in un articolo separato nella serie Scrum Guide.

Come utilizzare le User Stories?

Creare una User Story schematica è solo l’inizio. Sono segnali e punti di partenza per discussioni su problemi e le loro soluzioni. La discussione delle User Stories avviene durante la Pianificazione dello Sprint per chiarire quali questioni tecniche il team di Sviluppo aggiungerà allo Sprint Backlog.

Tipicamente, nello spazio fisico, le User Stories sono scritte su piccole schede colorate affisse nel luogo di lavoro. Tuttavia, nello spazio digitale, le lavagne digitali, condivise dal Team Scrum, funzionano meglio.

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

• Sottolinea l’autonomia di ogni User Story – ognuna ha un proprio contesto e può essere eseguita indipendentemente dalle altre
• Enfatizza la dinamica delle User Stories – l’ordine della loro realizzazione è rinegoziato dal Team Scrum e l’ordine attuale di realizzazione è visibile sulla lavagna grazie alla disposizione fisica delle schede con le User Stories
• Funziona come promemoria – grazie alla rappresentazione visiva delle User Stories, il Team Scrum ha un segnale visibile per ricordare loro l’obiettivo durante la creazione di soluzioni dettagliate.

Il Team di Sviluppo stima lo sforzo necessario per completare una User Story in giorni, ore uomo o Story Points.

Criteri di Accettazione

Una User Story deve avere determinati criteri di accettazione nel momento 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 completato.

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

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

È completata quando compare un pulsante “Acquista ora” funzionante sulla pagina del negozio online, che utilizza le informazioni di pagamento e spedizione predefinite per l’utente connesso.

Riepilogo

Una User Story è una descrizione concisa di una nuova funzionalità o miglioramento del Prodotto. Serve come il più piccolo Obiettivo espresso in linguaggio aziendale, cioè, dalla prospettiva del valore commerciale e dell’utente. Aiuta a definire chiaramente il compito da svolgere così come i criteri per il suo completamento.

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