Le storie utente costituiscono il cuore dello sviluppo agile. Sono l’input primario per il team scrum. Prende le user stories e crea incrementi di prodotto basati sul completamento di quelle storie. Sfortunatamente, ottenere delle user stories giuste non è così facile.
Puoi saperne di più sulle user stories qui:
I Product Owner devono imparare come creare user stories che soddisfino i bisogni del team. Per creare buone user stories, iniziate ricordando di INVESTIRE in buone user stories. INVEST è un acronimo che racchiude i seguenti concetti che compongono una buona storia utente:
Indipendente: Un Product Backlog Item (PBI) dovrebbe essere autonomo.
Negabile: Deve lasciare spazio alla discussione.
Valoroso: Deve fornire valore agli stakeholders.
Estimabile: Si deve sempre essere in grado di stimare la dimensione di un PBI.
Piccolo: Si dovrebbe quindi essere in grado di pianificare, assegnare compiti e priorità.
Testabile: Lo sviluppo dovrebbe poter essere testato.
Le storie dovrebbero essere il più possibile indipendenti e si dovrebbe essere in grado di lavorare su di esse in qualsiasi ordine. Questo permette una vera prioritizzazione di ogni singola storia. Quando entrano in gioco le dipendenze, potrebbe non essere possibile implementare una storia importante senza implementare altre storie molto meno importanti.
Negoziabile
Una buona storia è negoziabile e non un contratto. Una buona storia è un invito alla conversazione. Una buona storia cattura l’essenza di ciò che si desidera. Il risultato effettivo deve essere il risultato di una negoziazione collaborativa tra il Product Owner e il team di sviluppo. L’obiettivo è quello di soddisfare i bisogni del cliente.
Valoroso
Le storie degli utenti dovrebbero essere prioritarizzate nel backlog secondo il valore del business. Presentare elementi del product backlog che sono molto divertenti da codificare ma non portano alcun valore agli stakeholder, viola uno dei principi Agile, che è quello di fornire continuamente software di valore
Estimabile
Gli sviluppatori devono essere capaci di stimare una storia. Dovrebbe essere scritta in modo tale che gli sviluppatori possano capirla e avere un’idea di come implementarla. I fattori chiave per la stima sono la conoscenza del dominio e la conoscenza tecnica.
Piccole
Le buone storie tendono ad essere piccole, ma quanto piccole dovrebbero essere? La risposta dipende dal team e dalla metodologia utilizzata. Molti Product Owner suggeriscono iterazioni di due settimane, che permettono storie utente di tre o quattro giorni medi di lavoro. Questo include tutto il lavoro per portare la storia ad uno stato “fatto”.
Testabile
Le storie dovrebbero essere testabili per aiutare a determinare la completezza. Una storia dovrebbe avere un criterio di accettazione. Il criterio di accettazione dovrebbe essere oggettivo. Evitare di usare criteri come, facile da usare, veloce o senza bug. Try to write criteria that can be measured and tested.
Via: