Le user story sono costrutti semplici ma estremamente potenti: descrivono pezzi di funzionalità dal punto di vista di un utente, espressi in modo solido e compatto. Riflettono ciò che una particolare classe di esigenze degli utenti e il valore da ottenere. Il formato è molto semplice e facile da usare. Esistono diverse varianti, tra cui:
Perché le storie degli utenti?
Le storie degli utenti forniscono un modo eccellente per definire il tuo prodotto con chiarezza., Una serie di storie utente ben definite e con priorità può aiutarti a articolare la funzionalità del tuo prodotto utilizzando “plain English”, senza dettagli tecnici e di implementazione.
L’approccio “user story” consente discussioni significative sui prodotti, sia all’interno del team di sviluppo del prodotto che con gli stakeholder esterni.
Storie utente correttamente scritte forniscono una solida base per la comunicazione e la collaborazione — concentrandosi su ciò che conta di più per l’utente., Rispetto ad altri mezzi per catturare e documentare i requisiti degli utenti e le specifiche del prodotto, hanno almeno i seguenti vantaggi:
- Le storie degli utenti aiutano a ottenere chiarezza tra i team su cosa costruire, per chi, perché e quando. Dal momento che sono facili da definire, comprendere e rivedere, possono diventare il modo standard per comunicare e riassumere la funzionalità del prodotto da parte di membri tecnici e non tecnici. Sono estremamente utili per discussioni sul campo di applicazione del prodotto o come punti di ingresso per immersioni tecniche profonde. Sono elementi chiave dell’ingegneria agile.,
- Le storie degli utenti incoraggiano la partecipazione di membri non tecnici. I progetti software moderni sono in genere complessi e comprendono un’ampia gamma di tecnologie, acronimi e opzioni di implementazione. In molti casi, la terminologia o il linguaggio tecnico non sono comunemente compresi-anche all’interno di un singolo team — introducendo così “rumore” e rischi per il progetto. Le storie degli utenti rimuovono questa dimensione tecnica, quindi qualsiasi membro del team può contribuire, semplicemente pensando ‘come utente”., Il team può utilizzare un linguaggio non tecnico e collaborare efficacemente per definire, sfidare o dare priorità alle storie degli utenti. L’impatto sulla collaborazione e sulle dinamiche di squadra può essere significativo.
- Aiutano a definire l’intero prodotto — come un insieme di storie solide e saggiamente prioritarie. Il team di sviluppo del prodotto può pensare in grande, definire il super-set di storie utente e quindi assegnare priorità (che riflettono il valore atteso per l’utente, la complessità, le dipendenze e altre priorità aziendali). Non devi prendere decisioni difficili e contrassegnare gli elementi come “fuori portata”., Invece, è possibile assegnare una priorità inferiore a quelle idee ‘folli’, mentre lo spostamento verso l’alto le storie degli utenti che riflettono la funzionalità di base del prodotto. Definire le “linee di taglio” che determinano l’ambito per ogni iterazione, fase o versione, è quindi una questione di risorse disponibili e la velocità del team.
Scrivere grandi storie utente
Il formato è semplice, e scrivere storie è facile. Ma scrivere grandi potrebbe essere un po ‘ complicato. Ecco alcune linee guida da considerare:
Storie utente tasks attività
Le storie utente non sono attività., Infatti, una singola storia può avere bisogno di centinaia di singole attività per essere consegnato con successo. Le attività riguardano l’implementazione; le storie degli utenti riguardano la definizione.
Quando si compilano le storie, concentrarsi sulla fornitura di chiarezza circa le caratteristiche del prodotto — il cosa, non il come.
Rimanere di alto livello
È necessario essere di alto livello, ma anche preciso e to-the-point. Le storie devono essere semplici e solide. Ciò aiuterà i membri del team e le parti interessate a comprendere a fondo le esigenze degli utenti ed evitare di perdere tempo a chiarire parole d’ordine, terminologia e acronimi. Basta usare un linguaggio semplice e preciso.,
Comprendere gli utenti
È necessario scoprire e studiare gli utenti reali del vostro prodotto — catturare i loro profili, punti di vista, le aspettative, ei punti di dolore associati.”La ricerca degli utenti e altre tecniche possono generare approfondimenti per aiutarti a comprendere meglio gli utenti e le loro esigenze.
Non importa le tecniche, è necessario il set di utenti chiave-idealmente sotto forma di personas — prima di iniziare a compilare storie utente.,
Pensate a come un utente
<come una particolare classe di utente/ persona /ruolo> parte di una storia utente, definisce l’angolo, la prospettiva — come l’utente percepisce la funzionalità riassunti nella storia.
Questo è di fondamentale importanza: il proprietario del prodotto e l’intero team devono pensare dal punto di vista dell’utente e comprendere le esigenze sottostanti e il valore atteso.,
Think big
Quando si descrive un prodotto come un backlog di storie degli utenti, non c’è una buona ragione per limitare il tuo pensiero per budget, tempo, fattibilità o costo.
Una buona pratica è pensare in grande e lasciare che le storie degli utenti “folli” entrino nel backlog. Il sovraccarico amministrativo di mantenere un product backlog esteso è piccolo; il valore che ne deriva — in termini di chiarezza del prodotto, visione e opportunità — è enorme.,
Utilizzare epics
Epics può assumere la forma di storie di livello superiore, che descrivono grandi pezzi di funzionalità-in genere richiedono una notevole quantità di lavoro, su più sprint. Un altro modo di pensare alle epopee è come raggruppamenti / contenitori di storie correlate, più piccole, tutte al servizio di un obiettivo comune. I poemi epici sono buoni per organizzare le tue storie e fornire il quadro generale.,
Non scartare — priorità invece
Dato un processo di prioritizzazione efficace, è buona norma continuare ad arricchire il tuo product backlog con nuove storie utente, descrivendo nuovi scenari di interazione utente, “idee casuali” o l’output delle attività di innovazione del prodotto.
Per gestire il rumore potenziale, è necessario raggruppare correttamente e dare priorità alle nuove voci. In ogni caso, non filtrare/scartare gli elementi dal tuo backlog: gli elementi de-ambito vengono solitamente dimenticati, mentre gli elementi de-prioritari rimangono rilevabili e possono diventare rilevanti alle giuste condizioni.,
A seconda del contesto, dare priorità alle storie degli utenti può essere un processo complicato. È necessario stimare il valore di ogni storia, per l’utente e per il business. È necessario dimensionare la complessità, stimare la fattibilità e il costo / sforzo richiesto per costruire e rilasciare la funzionalità. È necessario identificare le dipendenze incrociate nel backlog, applicando un ordine specifico tra determinate voci.
Setup for success — non solo acceptance
I team spesso definiscono i test di accettazione degli utenti e i relativi criteri di accettazione. L’accettazione però non è sufficiente-è necessario impostare per il successo., Come product manager, hai bisogno di più di una conferma che “funziona come dovrebbe” o ” secondo le specifiche.’
Hai bisogno di metriche che siano anche collegate al feedback diretto degli utenti, catturando quanto siano felici e impegnati i tuoi utenti reali. Mentre l’accettazione è buona per controllare il ciclo di vita di sviluppo della funzione, il successo è di circa impatto a medio/lungo termine e il valore creato per gli utenti reali del vostro prodotto. È necessario definire entrambi – a livello di prodotto e / o epico e / o storia.
Tag storie, aggiungere metadati
Prodotti complessi richiedono centinaia di storie utente., Per facilitare la navigazione e l’amministrazione, devi nominare, classificare e taggare in modo efficace le tue storie. Dopo le prime revisioni di una storia, dovresti evitare di rinominare o cambiare drasticamente la sua descrizione in quanto ciò potrebbe introdurre confusione e lacune nella squadra.
Gestire correttamente i metadati delle tue storie-stato, progresso, collegamenti, priorità, risorse, ecc. – aiuta a esplorare, monitorare e capire il tuo backlog.
Non attaccare alle note appiccicose!,
Sì, un muro pieno di note appiccicose colorate sembra elegante e aiuta la tua squadra ad apparire occupata e produttiva 🙂 Ma hai bisogno di un sistema serio e di strumenti speciali per aiutarti a gestire, arricchire, dare priorità e condividere storie correttamente.,
In casi particolari, come un brainstorming o ideazione sessione, va bene per catturare la prima serie di storie utente utilizzando le note appiccicose—a condizione che si quindi il documento in un prodotto adeguato sistema di gestione. Se non lo fai, e basta tenere le vostre storie su note appiccicose, è probabile che vi perderete opportunità in termini di chiarezza, innovazione, efficienza e collaborazione.,
Hai ancora bisogno di specifiche
Avere una serie prioritaria di storie utente ben definite è fantastico, ma è solo l’inizio. Il team deve analizzare le storie – da un punto di vista tecnico-e creare gli artefatti tecnici necessari.
Idealmente, le storie sono mappate a una documentazione specifica che fornisce tutti i dettagli tecnici necessari dal punto di vista dell’ingegneria del software. Forniscono i punti di ingresso per i documenti dettagliati delle specifiche tecniche e altri artefatti dettagliati.,
La visualizzazione aiuta
Una visualizzazione (digitale) sempre attiva delle storie utente prioritarie per categoria, tema o epic potrebbe essere estremamente utile per la collaborazione e l’allineamento tra team e stakeholder. Insieme a statistiche, problemi, bloccanti e indicatori di avanzamento, una mappa storia può essere servita tramite schermi interattivi nello spazio collaborazione.
Le storie degli utenti forniscono un ottimo modo per descrivere in modo rapido e accurato la funzionalità di un prodotto o sistema software., Sono anche molto efficaci nel catturare i risultati di sessioni di brainstorming, sprint di progettazione, hackathon e altri processi guidati dall’innovazione, in cui un flusso di idee deve essere catturato in modo compatto e strutturato.