INVEST è un metodo per creare buone User Stories. Permette di verificare se contengono contenuti formulati correttamente e se si riferiscono al valore commerciale del Prodotto. E anche se la loro dimensione e usabilità sono state scelte correttamente.
Creare la migliore User Story con INVEST – indice:
- Introduzione
- I per Indipendente
- N per Negoziale
- V per Prezioso o Verticale
- E per Stimabile
- S per Piccolo
- T per Testabile
- 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
- Negoziale
- Preziosa
- Stimabile
- Piccola
- Testabile
Abbiamo scritto di più su cosa sia una User Story in un articolo separato. Qui, menzioneremo solo che è 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 caratteristiche dovrebbero essere comprensibili senza riferimento ad altre User Stories. Ma soprattutto, la sua realizzazione non dovrebbe correlarsi con altre User Stories. Naturalmente, non sarà una piena indipendenza. Non puoi dividere la creazione del Prodotto in moduli completamente separati. Tuttavia, è fondamentale ricordare di mantenere le User Stories il più indipendenti possibile. Grazie a ciò, anche se una di esse non entra nella fase di implementazione o viene significativamente modificata, le altre non dovranno essere modificate. Di norma, la User Story dovrebbe costituire un tutto separato e coerente.
N per Negoziale
La User Story dovrebbe essere negoziabile. Questo significa che stabilisce l’Obiettivo, non il modo per raggiungerlo.
In altre parole, definisce una caratteristica attesa del Prodotto, non una soluzione tecnica da implementare.
La negoziazione della User Story avviene tra il Product Owner e il Development Team. Il Product Owner propone l’implementazione di una certa funzionalità del Prodotto, cioè dice “Cosa” fare. Gli Sviluppatori sono responsabili di rispondere 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 rappresenta due qualità:
- Prezioso
- Verticale
Entrambi rivelano caratteristiche chiave di una buona User Story. Pertanto, abbiamo deciso di spiegare cosa significa ciascuna di esse.
Prezioso
Una User Story preziosa giustifica lo scopo commerciale della modifica. In altre parole, risponde accuratamente alla domanda sul perché introdurre la modifica e perché è 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 su “miglioramenti delle prestazioni” orizzontali in un livello selezionato del Prodotto. Al contrario, aggiunge un altro “livello” ad esso.
In altre parole, la User Story descrive come modificare il funzionamento complessivo di un Prodotto rispondendo alla domanda Cosa esattamente migliorare? Significa anche che ogni funzionalità del Prodotto si basa su soluzioni esistenti.
E per Stimabile
Una buona User Story dovrebbe essere stimabile. Questo significa che deve definire chiaramente l’ambito delle modifiche da apportare al prodotto affinché la User Story sia considerata completa. Questo consente al Development Team di determinare il tempo e lo sforzo necessari per completarla.
L’ambito e la difficoltà di un compito sono solitamente stimati in unità chiamate Story Points. Sono relativi. E ogni Development Team elabora il valore degli Story Points in pratica basandosi sull’esperienza precedente.
In articoli separati, abbiamo trattato di più su Velocità del Development Team e come misurarla.
S per Piccolo
La User Story accettata per la realizzazione dal Development Team deve essere concisa. Cioè, non dovrebbe essere più lunga di uno Sprint. Se gli Sviluppatori scoprono durante la Pianificazione dello Sprint che la User Story proposta dal Product Owner è troppo lunga, dovrebbero suddividerla 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 essere verificabile e sostenibile. In altre parole, dovrebbe essere possibile verificare se la soluzione implementata dagli Sviluppatori ha fornito il valore previsto a uno specifico Stakeholder.
Creare la migliore User Story – riepilogo
INVEST è un acronimo che descrive una User Story ben scritta. Dovrebbe essere:
- Indipendente da altre User Stories. In modo che possa essere modificata o rimossa dal Product Backlog se necessario.
- Negoziale. Dovrebbe specificare cosa fare lasciando la scelta di come farlo agli Sviluppatori.
- Preziosa, cioè giustificare il senso commerciale della modifica del Prodotto. O Verticale, cioè presentare una nuova funzionalità del Prodotto visibile all’Utente.
- Stimabile, significando avere una dimensione e un criterio di completamento definibili.
- Piccola abbastanza da essere completata in uno Sprint.
- Testabile in modo che si possa determinare con certezza che è stata implementata.
Se ti piace il nostro contenuto, unisciti alla nostra comunità di api operose su Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
Come Project Manager, Caroline è un'esperta nel trovare nuovi metodi per progettare i migliori flussi di lavoro e ottimizzare i processi. Le sue capacità organizzative e la sua abilità di lavorare sotto pressione temporale la rendono la persona migliore per trasformare progetti complicati in realtà.
Scrum Guide:
- Glossario dei termini, ruoli e nozioni di base
- Che cos'è Scrum?
- Valori Scrum
- Come implementare Scrum nella tua azienda?
- Team Scrum - cos'è e come funziona?
- Chi è un Product Owner?
- Gli errori più comuni del Product Owner
- Chi è lo Scrum Master?
- I più comuni errori del Scrum Master
- Quali statistiche e metriche dovrebbe monitorare lo Scrum Master?
- Team di sviluppo in Scrum
- I più comuni errori degli sviluppatori
- Artefatti Scrum
- Scaling Scrum
- Sprint Backlog
- Cos'è il Product Backlog?
- Cosa sono le User Stories?
- Creare la migliore User Story con INVEST
- I più comuni errori nelle User Story
- Criteri di accettazione della User Story
- Stima e Punti Storia in Scrum
- Planning Poker
- Gioco di Stima del Team
- Definizione di Incremento
- Eventi Scrum
- Che cos'è un grafico di burndown?
- Vantaggi e svantaggi del grafico di burndown
- Bacheche Kanban in Scrum e Scrumban
- Velocità nello Scrum - Velocità del Team di Sviluppo
- Daily Scrum Scrum giornaliero
- Pianificazione dello Sprint
- Revisione dello Sprint
- Che cos'è una Retrospettiva Sprint?
- Errori comuni durante una Retrospettiva di Sprint
- Nutrimento del Product Backlog
- Come creare e interpretare un grafico di burndown?