Guida Scrum | 21. Errori nelle User Story

Le User Stories descrivono come funziona una nuova funzionalità del prodotto in linguaggio quotidiano o aziendale. Tuttavia, la loro preparazione richiede molto tempo, impegno e riflessione. Nell’argomento di oggi, evidenziamo gli errori più comuni delle User Stories e suggeriamo come affrontarli.

Gli errori più comuni delle User Stories – indice:

1. Introduzione
2. Problemi con 3W
3. Problemi con 3C
4. Errori delle User Stories – Riepilogo

Introduzione

Le User Stories possono essere un ottimo strumento per motivare il team a proporre nuove soluzioni ai problemi presentati dalla prospettiva dell’utente. Abbiamo scritto su cosa sia una User Story in un articolo separato. E in questo articolo, abbiamo introdotto INVEST, che è un metodo popolare per scrivere buone User Stories. Oggi ci concentreremo sugli errori delle User Stories.

Problemi con 3W

Una User Story adeguata risponde alle domande:

• Chi? (Chi è l’utente target del prodotto?)
• Cosa? (Quali capacità ha il prodotto e cosa può fare?)
• Perché? (Qual è lo scopo?)

Tuttavia, problemi possono accompagnare le risposte a ciascuna di queste domande. Il problema meno comune è il dubbio su cosa dovrebbe cambiare nel prodotto in risposta alle esigenze del cliente. Pertanto, ci concentreremo sui problemi riguardanti Chi? e Perché?

Chi – persona utente

Uno degli errori più comuni commessi nella creazione delle User Stories è non rispondere alla domanda in modo sufficientemente preciso: per chi? In altre parole, chi è l’utente per cui è previsto il cambiamento?

Spesso una risposta generica che indica il Cliente o l’Utente Finale come destinatario del cambiamento non è sufficiente. La soluzione a questo problema è immaginare il destinatario come una persona specifica. Una persona è un’immagine modello del cliente target. In altre parole, una persona è una rappresentazione della persona che utilizzerà il prodotto in un modo specifico.

Dopo aver analizzato la tua User Story, potresti scoprire che racconta le storie di persone diverse contemporaneamente. Se ci sono molti utenti target, vale la pena considerare di suddividere la User Story in frammenti più piccoli per evitare azioni contraddittorie, mutuamente esclusive o semplicemente inefficaci.

Perché? – un obiettivo mal definito

A volte l’ultima sezione della User Story diventa la fonte di problemi. Dovrebbe specificare il valore commerciale delle modifiche apportate durante l’esecuzione della User Story. Dai un’occhiata a un esempio di errori delle User Story in cui la descrizione di funzionalità aggiuntive sostituisce l’obiettivo:

Come cliente, voglio acquistare una bacchetta magica con un clic perché voglio comprare un tappeto volante la prossima settimana.

Invece di fornire il motivo per cui si acquista la bacchetta magica, questa User Story aggiunge un altro elemento alla lista della spesa del potenziale cliente. Pertanto, quando prepari una User Story, non dimenticare i motivi per le modifiche nella funzionalità del prodotto.

Problemi con 3C

Possiamo suddividere il processo di lavoro con le User Stories in tre fasi chiamate 3Cs:

• Card – La scheda su cui è salvata la User Story
• Conversation – Una conversazione all’interno del Team Scrum riguardo alla scheda della User Story
• Confirmation – definire i criteri di accettazione che confermano che un compito è stato completato

Possono verificarsi errori in ciascuna di queste fasi, che descriviamo di seguito.

Card

La scheda di memoria che memorizza la User Story ha una capacità limitata. Pertanto, i problemi più comuni riguardano la lunghezza e il volume della User Story. La User Story ha bisogno di coerenza e di non girarci intorno, come si suol dire, a un grado così preciso che ogni parola conta.

Questo perché il problema della scheda della User Story ha due dimensioni. Una è il modo in cui è formulata: concisa e contenente un minimo necessario di enumerazione. La seconda è la dimensione effettiva della User Story. Una frase generale può esprimere un enorme numero di compiti che non possono essere completati durante uno Sprint singolo.

Conversation

La formulazione in una sola frase della User Story è il punto di partenza per una conversazione con il Team di Sviluppo. Pertanto, è errato trattarla come una descrizione del compito da eseguire. Disabilita la possibilità di negoziazioni e discussioni su vari modi di attuazione. La User Story non dovrebbe essere trattata come una descrizione dei requisiti per una nuova funzionalità del prodotto, ma piuttosto come un invito a iniziare una conversazione su soluzioni tecniche specifiche che porteranno alla realizzazione del valore commerciale definito dalla User Story.

Confirmation

Abbiamo scritto in dettaglio sui criteri di accettazione che devono essere definiti per ogni User Story nel testo che descrive cosa sia una User Story. Uno degli errori comuni, tuttavia, è la mancanza di vaghezza dei criteri di prestazione.

Una User Story ben scritta contiene una descrizione della situazione in cui viene implementata. Il suo test è che l’Utente sfrutti la nuova funzionalità creata dal Team di Sviluppo.

Uno strumento utile per convalidare la User Story è sviluppare un test di accettazione. Questo di solito si trova sul retro della scheda contenente la User Story.

Errori delle User Stories – Riepilogo

Quando si preparano e si applicano le User Stories, è utile attenersi alle seguenti regole:

• Identificare con precisione l’Utente interessato dal cambiamento
• Definire chiaramente lo scopo di costruire una nuova funzionalità del prodotto
• Mantenere il suo Volume il più breve possibile
• Trattare la User Story come un punto di partenza per discussioni con il Team di Sviluppo
• Stabilire regole chiare per l’accettazione

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