Guida Scrum | 20. INVESTIRE – Creare la migliore User Story

INVEST è un metodo per creare buone User Story. Consente di verificare se hanno contenuti adeguatamente formulati e se si riferiscono al valore commerciale del Prodotto. E inoltre, se le loro dimensioni e usabilità sono state scelte correttamente.

Creare la migliore User Story con INVEST – sommario:

1. introduzione
2. I per Indipendente
3. N per Negoziabile
4. V per Prezioso o Verticale
5. E per Stimabile
6. S per piccolo
7. T per testabile
8. Riepilogo

introduzione

INVEST è un acronimo creato da Bill Wake nel 2003 . Ogni lettera rappresenta l'inizio di una parola che caratterizza una buona User Story. Secondo il principio INVEST, ogni User Story dovrebbe essere:

• Indipendente
• Negoziabile
• Prezioso
• Stimabile
• Piccolo
• Testabile

Abbiamo scritto di più su cos'è la User Story in un articolo separato. Qui, menzioneremo solo che si tratta di una descrizione concisa di una nuova funzionalità del Prodotto scritta in un linguaggio accessibile.

I per Indipendente

La prima caratteristica di una buona User Story è la sua indipendenza. Significa che la sua descrizione e le sue caratteristiche dovrebbero essere comprensibili senza riferimento ad altre User Story. Ma soprattutto, la sua realizzazione non dovrebbe essere correlata ad altre User Story. Naturalmente, non sarà la piena indipendenza. Non puoi dividere la creazione del prodotto in moduli completamente separati. Tuttavia, è fondamentale ricordare di mantenere le User Story il più indipendenti possibile. Grazie a ciò, anche se uno di essi non entra in fase di attuazione o viene modificato in modo significativo, il restante non dovrà essere modificato. Di norma, la User Story dovrebbe costituire un insieme separato e coerente.

N per Negoziabile

La User Story dovrebbe essere negoziabile. Ciò significa che stabilisce l'Obiettivo, non il modo per arrivarci.

In altre parole, definisce una caratteristica prevista del Prodotto, non una soluzione tecnica da implementare.

La negoziazione della User Story avviene tra il Product Owner e il Team di sviluppo. Il Product Owner propone l'implementazione di alcune funzionalità del Prodotto, ovvero dice “Cosa” fare. Gli sviluppatori sono responsabili della risposta alla domanda "Come". Cioè, negoziare modi specifici per risolvere il problema presentato nella User Story.

V per Prezioso o Verticale

Nell'acronimo INVEST, la lettera V sta per due qualità:

• Prezioso
• Verticale

Entrambi rivelano le caratteristiche chiave di una buona User Story. Pertanto, abbiamo deciso di spiegare cosa significa ciascuno di essi.

Prezioso

Una preziosa User Story giustifica lo scopo commerciale della modifica. In altre parole, risponde accuratamente alla domanda sul perché introdurre la modifica e perché sia ​​importante dal punto di vista degli stakeholder.

Verticale

La seconda caratteristica; Verticale deriva dalla metodologia Agile. La User Story verticale contiene una nuova funzionalità del Prodotto visibile all'Utente. Cioè, non si concentra sul "miglioramento delle prestazioni" orizzontale in uno strato selezionato del Prodotto. Al contrario, aggiunge un altro "strato".

In altre parole, User Story descrive come modificare il funzionamento complessivo di un Prodotto rispondendo alla domanda Cosa migliorare esattamente? Significa anche che ogni funzionalità del Prodotto si basa su soluzioni esistenti.

E per Stimabile

Una buona User Story dovrebbe essere stimabile. Ciò significa che deve definire chiaramente l'ambito delle modifiche da apportare al prodotto affinché la User Story sia considerata completa. Ciò consente al Team di sviluppo di determinare il tempo e lo sforzo necessari per completarlo.

La portata e la difficoltà di un'attività sono generalmente stimate in unità chiamate Story Points. Sono relativi. E ogni team di sviluppo elabora il valore dei punti storia in pratica sulla base dell'esperienza precedente.

In articoli separati, abbiamo trattato di più sulla velocità del team di sviluppo e su come misurarla.

S per piccolo

La User Story accettata per la realizzazione dal Team di sviluppo deve essere concisa. Cioè, non dovrebbe essere più lungo di uno Sprint. Se gli sviluppatori scoprono durante lo Sprint Planning che la User Story proposta dal Product Owner è troppo lunga, dovrebbero dividerla in parti possibilmente indipendenti.

T per testabile

L'ultima lettera dell'acronimo INVEST sta per testabile. Significa che la modifica del Prodotto descritta nella User Story deve reggere ed essere verificabile. In altre parole, dovrebbe essere possibile verificare se la soluzione implementata dai Developer ha consegnato il valore ipotizzato a uno specifico Stakeholder.

Creazione della migliore User Story – riepilogo

INVEST è un acronimo che descrive una User Story ben scritta. Dovrebbe essere:

1. Indipendente da altre User Story. In modo che possa essere modificato o rimosso dal Product Backlog in caso di necessità.
2. Negoziabile. Dovrebbe specificare cosa fare lasciando la scelta di come farlo agli sviluppatori.
3. Prezioso , vale a dire che giustifica il senso commerciale di modificare il Prodotto. O Verticale, ovvero presentare una nuova caratteristica del Prodotto visibile all'Utente.
4. Stimabile , ovvero avente una dimensione definibile e un criterio di completamento.
5. Abbastanza piccolo da essere completato in uno Sprint.
6. Testabile in modo che possa essere determinato con certezza che è stato implementato.

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

Autore: Caroline Becker

In qualità di Project Manager, Caroline è esperta nella ricerca di nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la capacità di lavorare sotto pressione la rendono la persona migliore per trasformare in realtà progetti complicati.

Visualizza tutti i post

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