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.
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.
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:
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.
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é:
Il Team di Sviluppo stima lo sforzo necessario per completare una User Story in giorni, ore uomo o Story Points.
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.
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.
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à.
Diverse eventi più piccoli compongono uno Sprint in Scrum. Gli Sprint, a loro volta, formano…
I destinatari sempre più spesso si rivolgono ai materiali video. Le forme scritte diventano meno…
La scrittura pubblicitaria è diventata una professione estremamente popolare negli ultimi tempi. Ci sono sempre…
Hai mai la sensazione che la giornata sia troppo corta per fare tutto ciò che…
Che cos'è il software? Quali sono i tipi e i metodi di distribuzione? Rimanendo in…
Presentare e comunicare i risultati della ricerca è probabilmente una delle abilità più cruciali (e…