Sommopo

Tutti quelli che lavorano in scrum hanno una decisa confidenza con la user story, essendo questa l’elemento cardine del lavoro quotidiano sia del Product Owner, che le crea, che del team di sviluppo, che le trasforma in rilasci incrementali.

Una user story, si sa, rappresenta una singola funzionalità, o comunque uno sviluppo che risponde alla richiesta di un cliente o di uno stakeholder. Tanto più la funzionalità di una user story sarà isolata dalle funzionalità adiacenti, cioè tanto più sarà atomicamente tagliata, maggiore sarà la semplicità di trattamento della stessa.

Esiste un concetto che onestamente ho scoperto da poco di Comprehensive user story.

Per capirne la definizione, partiamo dalla struttura di una user story:
In quanto…. attore che beneficerà della funzionalità
voglio che… la funzionalità
così che… beneficio che deriverà dalla funzionalità
Acceptance criteria 1…n: sono criteri che vengono imposti alla realizzazione della funzionalità e integrano il default della definizione di done. Ad esempio:
– attore deve fare cliccare sul tasto e scatenare l’azione
– se l’attore non clicca sul tasto l’azione non si scatena

Eccoci al punto. La comprehensive user story parte dallo stesso presupposto di definizione funzionalità ma usa l’occasione fornitagli dagli acceptance criteria per immaginare tutti i possibili percorsi alternativi, o almeno quanti più possibile, quindi:
– attore deve fare cliccare sul tasto e scatenare l’azione
– se l’attore non clicca sul tasto l’azione non si scatena
– attore clicca su tasto, se sistema va in timeout esce messaggio x
– attore non capisce che deve cliccare il tasto per scatenare l’azione, legge help contestuale
– attore clicca sul tasto ma la batteria del laptop finisce; rientrando più tardi potrà verificare se l’azione è andata a buon fine e nel caso rilanciarla.
L’uso di CUS assicura che i membri del team e il product owner mantengano una visione completa delle varianti, minimizzano l’errore di usabilità, aiutano il tester a definire i test case. D’altronde la CUS può solo nascere da un lavoro di concerto tra Product Owner e tester, che meglio di ogni altro ha l’elasticità mentale e l’abitudine necessari a impersonificare le personas e ipotizzare scenari.

Non sono del tutto sicuro che ci sia una differenza così netta tra una Comprehensive User Story e una semplice User Story ben fatta, in altre parole non sono convinto della necessità di una ulteriore classificazione dei backlog items; in ogni caso cercherò di applicarne i principi e trarne i benefici a prescindere dal suo nome.