Come scrivere user story agili: 7 linee guida

Fondamentalmente, le user story agili sono strumenti brevi e semplici per documentare una singola azione o intenzione desiderata dall'utente mirato per raggiungere un obiettivo. Le storie degli utenti più semplici hanno un formato, "Come tipo o ruolo di utente , voglio agire o intento in  modo tale da giustificare o trarre vantaggio " che risponde ad almeno tre semplici domande su chi, cosa e perché la storia è nella coda di backlog.

Man mano che i team maturano e le organizzazioni utilizzano l'agile tra più team e iniziative, le user story agili spesso assumono molte più definizioni e strutture per garantire una comprensione condivisa dell'intento e dei requisiti sottostanti.

Iniziare a scrivere storie utente agili

Sono disponibili molte risorse per aiutare i nuovi proprietari di prodotti, gli analisti aziendali, i master di scrum e i lead tecnici a comprendere le basi della scrittura di user story. Alcuni punti da cui iniziare includono articoli di Atlassian, FreeCodeCamp, Agile Modeling e questi 200 esempi di storie utente. Uno dei commenti più completi si trova nella migliore user story agile di Alexander Cowan. Ci sono libri sulla scrittura di storie, tra cui User Story Mapping  di Jeff Paton e Peter Economy e User Stories Applied  di Mike Cohn. Puoi anche seguire corsi sulla scrittura di storie da Udemy, Learning Tree, VersionOne e Lynda.

Un principio fondamentale condiviso per la prima volta da Bill Wake è investire in buone storie . Invest  sta per "indipendente, negoziabile, prezioso, stimabile, piccolo e verificabile", che costituisce una buona lista di controllo per scrittori di storie agili. Un articolo che spiega come applicare i principi di investimento è  "Una guida agile per leader alla scrittura di storie utente" .

Le basi sono relativamente facili, ma spesso sento e sono testimone di disconnessioni tra parti interessate, proprietari di prodotti, sviluppatori e tester sulla qualità dei requisiti o se una storia è veramente finita. A volte ci sono punti di vista contrastanti sul livello di dettaglio richiesto, dove adattarsi ai requisiti tecnici e quali artefatti dovrebbero essere creati con le storie degli utenti.

Con queste domande in mente, ecco sette linee guida che vanno oltre le basi per scrivere storie utente agili.

1. Scrivi storie per il pubblico che le utilizzerà

Prima di scrivere storie, tieni presente che le storie devono essere lette e comprese da persone che partecipano al processo di sviluppo con esigenze e responsabilità diverse. Gli scrittori di storie e i contributori dovrebbero tenere a mente il pubblico e scrivere storie per soddisfare le esigenze collettive:

  • I proprietari dei prodotti potrebbero non essere quelli che scrivono le storie, soprattutto se la tua organizzazione delega questa funzione agli analisti aziendali o se ci sono più persone coinvolte nella scrittura della storia. I proprietari dei prodotti vogliono assicurarsi che la storia catturi pienamente le esigenze e le intenzioni degli utenti. Dovrebbero leggere i criteri di accettazione dettagliati ma non vogliono necessariamente essere impantanati con dettagli di implementazione tecnica. I proprietari dei prodotti dovrebbero anche capire in che modo la storia è allineata al quadro più ampio, quindi devono interessarsi attivamente a come vengono definite epiche e caratteristiche e come le storie vengono assegnate loro.
  • Le parti interessate non leggeranno i dettagli della storia, ma approfondiranno i poemi epici e leggeranno il riepilogo della storia. Se hai molte parti interessate, valuta la possibilità di utilizzare un formato descrittivo per i riepiloghi e di spostare la descrizione "Come tipo o ruolo utente " all'inizio della descrizione della storia utente.
  • I lead tecnici sono spesso la prima persona del team a rivedere le storie e studieranno i requisiti per vedere se una storia è troppo grande e dovrebbe essere suddivisa in più storie, o per vedere se la storia necessita di un lavoro tecnico iniziale per determinare la migliore soluzione.
  • L'assegnatario è la persona responsabile di esaminare i dettagli e riferire sui progressi nelle riunioni quotidiane. Gli assegnatari dovrebbero rivedere le storie per le dipendenze che possono diventare blocchi durante lo sprint.
  • I membri del team spesso esaminano tutte le storie per comprendere le storie assegnate nel contesto di altre storie assegnate allo sprint.
  • I tester determinano se ci sono lacune o rischi non identificati nei criteri di accettazione e quindi valutano il modo migliore per implementarli in framework di test automatizzati.
  • L'analista del team, che può essere un program manager o un membro dell'ufficio di gestione del progetto, desidera che le storie siano completamente etichettate e classificate in modo che le metriche significative possano essere estratte dal backlog.

2. Inizia con l'utente in mente

Sebbene le user story agili possano richiedere molti dettagli, è molto importante iniziare con l'utente in mente. La storia dovrebbe definire quale  azione o intento l'utente desidera realizzare e perché  ciò risponde a un'esigenza, un valore fondamentale o un obiettivo derivato dall'esperienza.

Per applicazioni più complesse, la definizione di diverse personalità utente che illustrano esigenze, valori e modelli di utilizzo di diversi tipi di utenti è una disciplina importante e può migliorare la scrittura di storie. In "10 suggerimenti per scrivere buone storie utente", Roman Pichler suggerisce che "gli obiettivi personali ti aiutano a scoprire le storie giuste. Chiediti quale funzionalità dovrebbe fornire il prodotto per soddisfare gli obiettivi dei personaggi ". L'utilizzo di personas per rafforzare gli obiettivi degli utenti fornisce un significato più ricco del motivo per cui una storia è importante e aiuta a dare la priorità al backlog.

3. Rispondi perché la storia è importante

Comprendere, documentare e discutere le esigenze degli utenti o gli obiettivi della personalità dell'utente è solo una dimensione del motivo per cui il proprietario del prodotto dà la priorità alle storie. La storia dovrebbe anche fornire un valore commerciale, qualcosa che è difficile da quantificare ma può essere qualificabile  a livello di storia, caratteristica, epico o rilascio.  

Rispondere al perché  può essere importante per gli sviluppatori quando hanno il potere di proporre diverse opzioni di implementazione. Ad esempio, una funzionalità che migliora l'esperienza di accesso per gli utenti può anche avvantaggiare l'azienda se la nuova esperienza genera anche dati migliori sui clienti. Uno sviluppatore può riflettere su questo valore di business aggiunto e ottimizzare l'implementazione per questo obiettivo anche se i criteri di accettazione della storia non sono specifici su questo requisito.

4. Definire i criteri di accettazione senza prescrivere una soluzione

La disciplina più significativa su cui concentrarsi nella scrittura di una storia è la stesura dei criteri di accettazione. Si tratta spesso di elenchi puntati di brevi dichiarazioni di esito positivo o negativo che documentano requisiti, vincoli, metriche e aspettative. Questi criteri di accettazione vengono spesso utilizzati in diversi modi:

  • I responsabili tecnici ei team li usano per stimare i punti della storia in base alla complessità e all'impegno.
  • Gli sviluppatori restringono le opzioni di implementazione a quelle che soddisfano i criteri di accettazione.
  • I proprietari dei prodotti possono ridurre l'ambito o la complessità dei criteri di accettazione per guidare le implementazioni con stime inferiori.
  • L'assegnatario comunica blocchi o problemi che soddisfano criteri difficili durante gli standup.
  • Gli ingegneri del controllo qualità utilizzano criteri di accettazione per sviluppare test automatizzati.
  • Il proprietario del prodotto esamina i criteri chiave durante la demo agile per garantire che la storia sia finita .

Scrivere criteri di accettazione non è banale. I criteri di accettazione per i criteri di accettazione evidenziano alcune delle questioni come fornire troppi criteri, definire criteri troppo vaghi o documentare criteri complessi che non possono essere facilmente verificati. Alcuni autori utilizzano modelli di criteri di accettazione che definiscono una struttura per criteri brevi, atomici e verificabili.

5. Usa le storie per definire cosa e perché; definire le attività su come implementare

Uno degli errori critici che vedo commettere dai team riguardo alla scrittura di una storia è essere dettagliati e specifici riguardo all'implementazione. Queste storie scritte male investono molto impegno nel descrivere come implementare spesso a scapito di descrivere ciò di cui l'utente ha bisogno, perché  si rivolge ai suoi obiettivi e dove  genera valore aziendale.

Ci sono alcuni motivi per cui questo potrebbe accadere.

I proprietari di prodotti inesperti possono utilizzare le storie per dipingere le loro visioni di implementazione. In altre parole, potrebbero specificare eccessivamente il design dell'utente e le implementazioni funzionali invece di condividere l'esperienza e i vantaggi dell'utente target. Alcuni proprietari di prodotti confondono la loro concettualizzazione di come qualcosa potrebbe  funzionare (il processo mediante il quale arrivano a comprendere i requisiti) con come dovrebbe  funzionare, trasformando accidentalmente un esempio di implementazione interna in una specifica di implementazione esterna.

Altri proprietari di prodotti potrebbero oltrepassare i propri limiti chiedendo al team di "costruirmi questo". Questo è uno dei miei 20 cattivi comportamenti dei proprietari dei prodotti, per i quali ho consigli ai proprietari dei prodotti sulla collaborazione con il team sulle soluzioni.

L'altro motivo per cui le storie possono essere ingombre di dettagli di implementazione è che alcuni team e responsabili tecnici desiderano questo livello di dettaglio. I team tecnici appena formati che lavorano per migliorare le applicazioni esistenti potrebbero desiderare questo livello di dettaglio fino a quando non capiranno meglio come funziona l'applicazione e comprenderanno appieno le esigenze degli utenti. Alcuni team distribuiti che lavorano con sviluppatori offshore o freelance potrebbero anche voler documentare i dettagli di implementazione per garantire che questi membri comprendano le loro responsabilità.

Per tali team, la cosa migliore da fare è collegarsi ai diagrammi di implementazione e documentare chi sta facendo cosa e come come attività legate alla storia. La maggior parte degli strumenti di gestione agili consentono attività o attività secondarie e questo livello di dettaglio è solitamente separato dal corpo della storia. Un diagramma in questo post fa un buon lavoro che illustra questo importante principio dell'utilizzo di storie agili per abbattere le esperienze degli utenti e i processi aziendali e l'aggiunta di attività per definire l'implementazione di singole parti di lavoro.

6. Tagga le tue storie per guidare l'analisi e migliorare la pratica

Una volta che le storie sono state scritte, elaborate e completate, molti team cercano di acquisire metriche ed eseguire analisi che possono guidare il miglioramento dei processi o utilizzate per creare casi aziendali per investimenti aggiuntivi.

Ecco alcuni esempi:

  • Etichetta le storie come debito tecnico per quantificare l'entità del debito, la percentuale della velocità del team utilizzata per risolverlo e il debito totale completato con ogni rilascio.
  • Definisci storie di picchi funzionali e tecnici per guidare la sperimentazione e l'innovazione, quindi riferisci su dove sta avendo impatto sul business.
  • Se il tuo team sta valutando le user story agili, chiedi al team di taggare le storie alla fine dello sprint per segnalare se hanno sovrastimato o sottostimato per migliorare l'accuratezza delle stime.
  • Utilizza etichette, componenti e campi personalizzati per facilitare la ricerca nel backlog di comprensioni o metriche storiche. Ad esempio, è possibile sapere quali storie hanno influenzato le API o quali requisiti hanno portato agli ultimi miglioramenti funzionali a un'area specifica dell'applicazione quando le storie sono contrassegnate con componenti funzionali e tecnici.
  • Tagga storie che raccolgono o elaborano informazioni sensibili come informazioni di identificazione personale (PII), transazioni di e-commerce o dati regolamentati dal settore come i dati HIPAA per consentire revisioni di sicurezza e conformità.
  • Fornire feedback al proprietario del prodotto e al team. Oltre a segnare una storia fatta , un proprietario del prodotto potrebbe anche fornire feedback al team, ad esempio riconoscendo un ottimo lavoro . Allo stesso modo, il team può fornire feedback al proprietario del prodotto sulla qualità e interpretabilità complessive di una user story.

7. Definisci modelli di storia e guide di stile agili

Le organizzazioni più grandi che lavorano con più team agili e proprietari di prodotti potrebbero voler redigere standard e guide di stile per la scrittura di storie. La coerenza aiuta i nuovi proprietari di prodotti ad apprendere le capacità di scrittura più velocemente e migliora anche l'efficienza dei membri del team nell'utilizzo delle informazioni.

Un altro motivo per progettare modelli di storie è che diversi tipi di prodotti e applicazioni si prestano a diverse espressioni e artefatti di storie utente. Qualche esempio:

  • Le storie dei processi aziendali possono richiedere collegamenti ai diagrammi del flusso di lavoro e specificare anche ruoli e autorizzazioni.
  • Le storie di applicazioni rivolte ai clienti dovrebbero avere collegamenti a wireframe e includere criteri di prestazione.
  • Le storie delle API dovrebbero documentare i modelli e le metriche di utilizzo previsti.
  • Le storie di business intelligence e visualizzazione dei dati dovrebbero fornire linee guida su quali campi e informazioni sono necessari per l'analisi richiesta.

I modelli aiutano a colmare la comunicazione tra i team e i proprietari dei prodotti su cosa concentrarsi quando si scrivono storie agili.

E non è questo il punto delle storie agili? Pratiche, linee guida e principi di scrittura di storie agili sono lì per aiutare i team a sapere cosa è importante per gli utenti e per l'azienda prima di considerare come implementarli.