Le user stories sono il punto di inizio per poter descrivere un prodotto rispetto al modo con il quale un utente lo utilizzerà. Sono il punto focale che descrive le caratteristiche del prodotto e il valore che il prodotto riconosce ad ogni utente.
Le user stories sono poi elaborate, prodotte e il derivante prodotto è offerto agli utenti che decreteranno il successo o il fallimento dell’offerta.
Si sa che una user story nella sua definizione non vuole e non può essere esaustiva. Le tre C che identificano una user story ci dicono che
- i requisiti devono essere sintetici secondo la prima C (Card)
- per via della loro natura, non sono esaustive e devono abilitare la conversazione (Conversation)
- i requisiti devono poter essere controllati (Confirmation)
Pertanto non ci si aspetta che una user story descriva minimamente tutti le caratteristiche e gli stati eccezionali del prodotto, ma che vada a far si che una molteplicità di teste possano ragionare su quei concetti specifici.
Ci sono però delle caratteristiche in più che è necessario considerare quando il Product Owner descrive un product backlog con un insieme di User Stories. Da qui ci si può rifare all’acronimo di Bill Wake: INVEST.
Nella nostra esperienza una user story non deve essere solo in linea con il principio delle 3C, ma deve avere una serie di caratteristiche intrinseche in più. Deve essere (I) Indipendente, (N) Negoziabile, (V) Valutabile, (E) Stimabile, (S) Piccola e in fine Testabile.
(I) User stories Indipendenti
Avere un backlog fatto di user stories che hanno queste caratteristiche, permette di avere un backlog a sua volta molto versatile in cui le priorità possono cambiare la sequenza di lavorazione delle user stories stesse senza la necessità di dover ripensare a tutto.
Non essendoci dipendenza tra le singole user stories permette di avere delle singole stime molto precise ed evita che la stima di una user story sia influenzata da un’altra.
Per disaccoppiare le user stories da altre si possono usare diverse strategie. Essendo noi prevalentemente di estrazione tecnica abbiamo notato che le tecniche di disaccoppiamento utilizzate nell’obiect orientation come il pattern Factory o il pattern Strategy possono venire utili e permette a user stories di poter essere, a loro volta, disaccoppiate.
(N) User stories Negoziabili
Lo Sprint Planning meeting e eventuali incontri precedenti sono i momenti in cui si scoprono le carte e si manifesta ciò che si vuole venga sviluppato. La necessità di abilitare la conversazione di una user story, viene proprio in questo momento. Le user stories devono abilitare alla conversazione, ma è anche opportuno che durante questi incontri la conversazione che ne deriva venga in qualche modo documentata. Nella nostra esperienza, durante gli Sprint Planning meeting abbiamo preso nota di quello che succedeva, modificando o creando i paper prototype oppure andando a definire già da quel momento un possibile documento di Deploy utile all’analisi del dimensionamento fisico della soluzione.
(V) User stories che siano Valutatabili
Ogni user story deve produrre valore per un utente. Questo è il mantra del Product Owner. Con questo mantra, il Product Owner, riesce a impersonificare l’utente e a capire quale è la priorità da attribuire poi alla singola user story.
Nella nostra esperienza abbiamo sempre cercato di capire quanto è il valore in termini di beneficio e di penalità rispetto all’avere o al non avere quella user stories implementata. Poi attraverso l’approccio di Wieger alla prioriticizzazione arriviamo a definire quali user stories entrano prima nella roadmap e quali entrano dopo.
(E) User stories che siano Stimabili
Riuscire a stimare le user story è il primo segnale per capire se la user story è scritta bene oppure no. Non riuscire a dare una stima, vuol dire che la sua definizione è troppo generica. La stima, nella nostra esperienza, l’abbiamo vista anche come un elemento time boxed. Siamo consapevoli che anche nello sviluppo del software una determinata funzionalità può essere sempre rifinita e tale processo può anche diventare eterno. La stima permette di identificare delle costrizioni temporali per andare ad implementare solo il necessario della storia e non tutto. Quando pensiamo a stimare a una storia consideriamo sempre il principio di Pareto, in cui il 20% della storia produce l’80% del valore. Questo è il punto in cui lavoriamo quando andiamo a stimare una storia. Secondo l’approccio di Wieger, mischiato con il principio di Pareto riusciamo ad implementare per prime solo le user stories che danno maggior beneficio, danno maggiore penalità e costano il meno possibile in termini di complessità.
(S) User stories che sono Piccole
Se le user stories son a granularità fine, è permessa una maggiore accuratezza durante le stime. Di solito separiamo le storie in relazione anche al loro modo di gestire le informazioni. Generalmente separiamo tutte le CRUD operations come singole user stories diverse.
(T) User stories che sono Testabili
La Confirmation di una user stories ci spinge a dover scrivere un acceptance test per la user story stessa. Ci sono anche degli altri test che devono essere passati nel frangente di una singola storia. I test non funzionali fanno parte dell’insieme di test che solitamente cerchiamo di isolare per ogni singola storia.
I test funzionali, nella nostra esperienza, devono essere il più possibili automatizzati. Utilizziamo tools come Fitnesse o Selenium per creare dei test funzionali di regressione. Separiamo genericamente la presentation in HTML e Javascript e in un server che è invocato via AJAX tramite delle API.
Attraverso piattaforme come Fitnesse cerchiamo di testare tutte le invocazioni di business fatte via API con una conseguenza di chiamata delle singole API (es. un workflow). La presentation invece la testiamo abitudinalmente con strumenti come QUnit. In questo modo riusciamo ad avere una suite di test per le user stories sulle API e una serie di test unitari sul frontend.
Con queste nostre pratiche evidenziate, INVESTire sulle singole user stories è un atto a cui il Product Owner deve dare rilievo. La completezza dei requisiti e il soddifacimento del principio delle tre C e del principio di INVEST fa si che il prodotto possa evolvere agevolmente giorno dopo giorno.