Guida Scrum | 21. Errori della User Story

Le User Story descrivono come funziona una nuova funzionalità del Prodotto nel linguaggio quotidiano o lavorativo. Tuttavia, la loro preparazione richiede molto tempo, impegno e riflessione. Nella voce di oggi, segnaliamo gli errori di User Story più comuni e suggeriamo come affrontarli.

Gli errori più comuni della User Story – sommario:

1. introduzione
2. Problemi con 3W
3. Problemi con 3C
4. Errori della User Story – Riepilogo

introduzione

La User Story può essere un ottimo strumento per motivare il team a proporre nuove soluzioni ai problemi presentati dal punto di vista dell'utente. Abbiamo scritto su cos'è la User Story in una voce separata. E in questo articolo, abbiamo introdotto INVEST, che è un metodo popolare per scrivere buone User Story. Oggi ci concentreremo sugli errori della User Story.

Problemi con 3W

Una User Story corretta risponde alle domande:

• Chi? (Chi è l'utente target del Prodotto?)
• Che cosa? (Quali capacità ha il Prodotto e cosa può fare?)
• Come mai? (A che scopo serve?)

Tuttavia, i 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 relativi a Who? e perché?

Chi: persona dell'utente

Uno degli errori più comuni commessi durante la creazione di User Story è non rispondere in modo sufficientemente preciso alla domanda: per chi? In altre parole, chi è l'utente a cui è destinata la modifica pianificata?

Spesso non basta una risposta generica che indichi il Cliente o l'Utente finale come destinatario della modifica. 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 allo stesso tempo. Se ci sono molti utenti target, vale la pena considerare di dividere la User Story in frammenti più piccoli per evitare azioni contraddittorie, che si escludono a vicenda o semplicemente inefficaci.

Come mai? – un obiettivo poco definito

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

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

Invece di fornire il motivo dell'acquisto della bacchetta magica, questa User Story aggiunge un altro articolo alla lista della spesa del potenziale cliente. Pertanto, nella preparazione di una User Story, non dimenticare le ragioni delle alterazioni della funzionalità del Prodotto.

Problemi con 3C

Possiamo suddividere il processo di lavoro con le User Story in tre fasi chiamate 3C:

• Carta – La carta su cui è salvata la User Story
• Conversazione – Una conversazione all'interno dello Scrum Team sulla scheda User Story
• Conferma : definizione dei criteri di accettazione che conferma che un'attività è stata completata

Gli errori possono verificarsi su uno qualsiasi di questi, che descriviamo di seguito.

Carta

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 senza giri di parole, come si suol dire, a un livello così preciso che ogni parola conta.

Questo perché il problema della scheda User Story ha due dimensioni. Uno è il modo in cui è formulato: conciso e contenente una quantità minima necessaria di enumerazione. Il secondo è gla dimensione effettiva della User Story. Una frase generale può esprimere un numero enorme di attività che non possono essere completate durante un singolo Sprint.

Conversazione

La formulazione in una frase della User Story è il punto di partenza per una conversazione con il Team di Sviluppo. Pertanto, non è corretto trattarlo come una descrizione dell'attività da svolgere. Disabilita la possibilità di negoziazioni e discussioni sulle varie modalità della sua attuazione. La User Story non deve essere trattata come una descrizione dei requisiti per la funzionalità di un nuovo prodotto, ma piuttosto un invito ad avviare una conversazione su soluzioni tecniche specifiche che porteranno alla realizzazione del valore aziendale definito dalla User Story.

Conferma

Abbiamo scritto in dettaglio i criteri di accettazione che devono essere definiti per ciascuna User Story nel testo che descrive cos'è 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 le nuove funzionalità create dal Team di Sviluppo.

Uno strumento utile per validare la User Story è sviluppare un test di accettazione. Di solito si trova sull'altro lato della carta contenente la User Story.

Errori della User Story – Riepilogo

Quando si preparano e si applicano le User Story, vale la pena attenersi alle seguenti regole:

• Identificare con precisione l'Utente interessato dalla modifica
• Definire chiaramente lo scopo della creazione di nuove funzionalità del prodotto
• Mantieni il suo volume il più breve possibile
• Considera la User Story come un punto di partenza per le discussioni sulla soluzione con il team di sviluppo
• Stabilire regole chiare per l'accettazione

Se ti piacciono i nostri contenuti, unisciti alla nostra indaffarata community di api su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Guida alla mischia:

1. Glossario di termini, ruoli e nozioni di base
2. Cos'è Scrum?
3. Valori di mischia
4. Come implementare Scrum nella tua azienda?
5. Scrum Team: cos'è e come funziona?
6. Chi è un Product Owner?
7. Gli errori più comuni del Product Owner
8. Chi è lo Scrum Master?
9. Caratteristiche di un buon Scrum Master
10. Gli errori più comuni di Scrum Master
11. Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
12. Collaborazione tra Product Owner e Scrum Master
13. Team di sviluppo in Scrum
14. Gli errori più comuni degli sviluppatori
15. Artefatti di Scrum
16. Scalare Scrum
17. Sprint arretrato
18. Cos'è il Product Backlog?
19. Cosa sono le User Story?
20. Creare la migliore User Story con INVEST
21. Gli errori di User Story più comuni
22. Criteri di accettazione della User Story
23. Stima e Punti Storia in Scrum
24. Pianificazione del poker
25. Gioco di stima della squadra
26. Incremento di definizione
27. Eventi Scrum
28. Cos'è lo Sprint in Scrum?
29. Impegni dello Scrum Team - Obiettivo del prodotto, Obiettivo dello Sprint e Definizione del completamento
30. Che cos'è un diagramma di burndown?
31. Come creare e interpretare un diagramma di burndown?
32. Vantaggi e svantaggi del diagramma di burndown
33. Tavole Kanban in Scrum e Scrumban
34. Velocity in Scrum - Velocità del Team di Sviluppo
35. Scrum quotidiano
36. Pianificazione dello sprint
37. Recensione Sprint
38. Che cos'è una retrospettiva sprint?
39. Errori comuni durante una Retrospettiva Sprint
40. Consolidamento del Product Backlog