Storie utente in Scrum: tutto quello che devi sapere

L’obiettivo è chiaro: vuoi sviluppare un prodotto che offra un elevato valore aggiunto ai clienti. Vuoi ottenere un risultato di cui i membri del team e gli stakeholder siano soddisfatti. Ma come puoi raggiungere questo obiettivo? Come puoi soddisfare tutti i requisiti di un prodotto in piccoli e accurati passi? 

In Agile, le storie utente si sono dimostrate uno strumento efficace a questo scopo. Ti portano passo dopo passo dalla prima idea a un prodotto pronto per la vendita. Ti mostrerò cosa sono le storie utente, come crearle e come puoi trarne vantaggio.

La definizione di user stories in Agile descrive i requisiti di un prodotto dal punto di vista dell’utente. In altre parole, le storie dell’utente indicano le caratteristiche e le funzioni che un prodotto dovrebbe avere. Questo le rende uno strumento fondamentale per discutere e convalidare le esigenze degli utenti e lavorare alla loro implementazione con un’intesa comune. 

Le storie utente offrono un linguaggio universale che i membri del team, gli stakeholder e i clienti comprendono e parlano. In pratica, questo significa che puoi usare le storie utente per sviluppare una comprensione del prodotto desiderato dal cliente che lasci poco spazio ai fraintendimenti. 

Più storie utente insieme formano un caso d’uso. Le storie degli utenti hanno origine nello sviluppo software Agile.

Le storie utente descrivono i requisiti e i desideri di un risultato di progetto da creare dal punto di vista del cliente o dell’utente. Le storie utente di Agile hanno questa struttura elementare:

OMS (ruolo), vuole COSA (obiettivo/desiderio) PERCHÉ (valore aggiunto)?

Diamo un’occhiata più da vicino ai singoli componenti delle storie utente:

CHI (UTENTE)

Il segnaposto WER viene riempito con il tuo cliente o con un rappresentante tipico del tuo gruppo target. Il grado di dettaglio con cui descrivi l’OMS nella User Agile Story dipende dalla user story stessa e dall’andamento del progetto. Pertanto, sii abbastanza dettagliato da creare una storia utente significativa.

COSA (FUNZIONE)

È qui che si collocano i desideri dell’utente. Puoi chiederti cosa si aspetta o di cosa ha bisogno l’utente. Se il tuo prodotto è ancora in una fase iniziale di sviluppo, puoi formulare delle ipotesi basate sulla tua esperienza su quali funzioni si aspetta l’utente. Se hai già un prodotto simile sul mercato, puoi anche ricavare le funzioni desiderate dal feedback su questo prodotto.

PERCHÉ (VALORE AGGIUNTO)

È solo il valore aggiunto che dimostra perché una funzione è importante per l’utente. Il PERCHÉ ti permette quindi di riflettere onestamente su quanto bene conosci le esigenze di un cliente. Perché: è facile includere un requisito in una user story, ad esempio perché il cliente esprime il desiderio di farlo. Ma solo quando capisci perché il cliente ne ha bisogno, hai il contesto per implementare il requisito. Solo allora puoi chiederti se la proposta/desiderio del cliente soddisfa in modo efficiente la sua reale esigenza o se c’è un modo più intelligente. Vediamo un esempio: 

Il cliente desidera una mantella antipioggia per andare in bicicletta. Potresti quindi includere il requisito “mantellina da pioggia”. Oppure potresti chiedere al cliente perché ha bisogno di una mantellina da pioggia. Supponiamo che il cliente risponda “Perché non voglio bagnarmi”. 

Ciò significa che non devi necessariamente fornire un impermeabile. Potresti anche fornire una bicicletta con un tetto integrato. La cosa decisiva è che il bisogno o il problema del cliente sia risolto, ovvero non bagnarsi. Quanto meglio comprendi il “perché”, tanto meglio puoi progettare la tua user story.

Cosa sono le User Stories in Agile (esempio)?

Ora conosci i singoli componenti delle Agile User Stories. Un esempio di User Story Agile potrebbe essere questo: 

Come CLIENTE Vorrei UNA PASSWORD SICURA***,*** IN MODO DA PROTEGGERE I DATI DEI MIEI CLIENTI.

Ecco il sito “CLIENTE” l’utente, “UNA PASSWORD SICURA”. la funzione e “IN MODO CHE I DATI DEI MIEI CLIENTI SIANO PROTETTI”. il valore aggiunto. 

Quando lavori con le storie utente in Scrum, aggiungi ad esse dei criteri di accettazione. I criteri di accettazione descrivono i requisiti tecnici che le storie utente devono soddisfare al momento dell’accettazione. In altre parole: I criteri di accettazione sono i requisiti necessari affinché una storia utente crei valore.

L’importanza delle storie utente Agile nel backlog può essere più differenziata. Perché: nei backlog, le storie utente non solo descrivono i requisiti, ma rappresentano anche un tipo di gerarchia speciale. Esistono 3 tipi di gerarchia:

Epopee: Le epiche sono aree funzionali ampiamente definite di un prodotto il cui ambito concreto può essere ancora poco chiaro.

Caratteristiche: Le funzionalità sono caratteristiche specifiche delle prestazioni di un’epica.

Storie: Le storie sono storie di utenti tecnici Agile e storie di utenti all’interno di una caratteristica.

Puoi implementare questi tipi di gerarchia all’interno di uno sprint. Creano un vantaggio concreto per l’utente. 

Per scrivere storie utente utili nella gestione agile del progetto, sono fondamentali discussioni dettagliate con tutti gli stakeholder. Questi dovrebbero fornirti una comprensione completa del gruppo target e del prodotto da creare. Da questo puoi ricavare, ad esempio, le personas. 

Inoltre, il cosiddetto Criteri di INVESTIMENTOper creare una storia utente convincente:

Indipendente: Una storia utente deve essere indipendente da altre storie utente. Ciò significa che l’implementazione di una storia non deve presupporre che un’altra storia sia stata implementata in precedenza. Questo ha il vantaggio di poter dare priorità alle storie utente o rimuoverle dal backlog in qualsiasi momento. 

Riprendiamo l’esempio della bicicletta. Supponiamo che tu abbia deciso di installare un piccolo tettuccio sulla sella della bicicletta invece di una mantella per la pioggia, in modo che il cliente non si bagni più. Questa sarebbe una storia utente. Ma ora ti rendi conto che per avere un tetto devi prima sviluppare una sella più stabile a cui fissare il tetto. Questa sarebbe un’altra User Story. Entrambe le Storie si basano l’una sull’altra. Questo è esattamente ciò che dovresti evitare.

Naturalmente, a volte è inevitabile che tu debba realizzare una user story prima di un’altra. Ma come regola generale, evita le storie utente per le quali devi prima implementare altre 20 storie utente.

Trattabile: Scrivere User Stories a volte può richiedere molto tempo, ma non dovrebbe essere scolpito nella pietra in seguito. Ciò significa: Proprietario del prodotto Gli stakeholder e gli sviluppatori dovrebbero sempre discutere e perfezionare insieme una user story. 

Prezioso: Il risultato delle storie utente nella gestione agile del progetto deve avere un valore aggiunto per il cliente.

Stimabile: Una user story convincente permette al team di sviluppo di stimare l’impegno necessario per implementarla.

Piccolo: Una user story dovrebbe essere così “piccola” da poter essere realizzata in un solo sprint.

Testabile: Le storie degli utenti in Scrum devono essere testabili. Questo è l’unico modo per verificare se possono essere realmente implementate nella pratica.

Se non hai familiarità con la scrittura di storie utente in Agile, potrebbero sembrare solo un lavoro extra. Tuttavia, le storie utente forniscono ai team un contesto importante per i loro compiti, chiarendo ulteriormente l’importanza di ogni attività.

In pratica, ecco come trarre vantaggio dalle Storie degli Utenti:

Focus sull’utente: Le storie utente sono come una lista di cose da fare orientata al problema. Il tuo team può usarle per tenere traccia dei propri compiti e sapere esattamente come soddisfare le esigenze degli utenti.

Cooperazione olistica: Le storie dell’utente mostrano a tutti i partecipanti a colpo d’occhio come stanno andando le cose. In questo modo, tutti possono collaborare e decidere più volte come l’utente riceverà un valore aggiunto particolarmente elevato. 

Soluzioni creative: Creare storie utente nello sviluppo software agile risultati creativi . Perché: inducono i team a pensare in modo critico alla soluzione migliore per il prodotto finale.

Successi consistenti: Ogni User Story è una piccola sfida. I team possono quindi festeggiare un piccolo successo dopo ogni storia. Questo motiva l’intero processo di sviluppo.

Le storie utente sono uno strumento importante nel lavoro dei team agili. Mostrano più volte nel dettaglio per chi si sta sviluppando cosa e perché. Questo non solo ti aiuta a creare un prodotto di alta qualità e adatto al gruppo target, ma anche a mantenere il team motivato durante l’intero processo. 

Per avere successo a questo macro livello di lavoro agile, la tua organizzazione nel suo complesso deve pensare e funzionare in modo agile. Per sostenere te e la tua organizzazione in questo senso, abbiamo collaborato con esperti di fama per creare Progetto Scagile progettato. Questo ti mostra in vari webinar come affrontare correttamente una trasformazione agile. La formazione è gratuita. Non esitare a dare un’occhiata!

Se vuoi avere delle domande più varie per le tue retrospettive, dai un’occhiata al nostro post su 32 metodi retrospettivi freschi per principianti e professionisti (con, tra gli altri, Mario Kart Retro, Marathon Retro e Elon Musk Retro).

Uno dei modi migliori per sviluppare in modo sostenibile la mentalità agile dei membri del team è implementare un Agile Health Check. Il nostro kit gratuito Team Health Check può aiutarti a porre le domande giuste: dai un’occhiata.