Una guida per scrivere user stories
Quest’estate, mentre ero alla ricerca di titoli relativi al product management e alla raccolta dei requisiti, mi sono imbattuta in un piccolo manualetto dal titolo “Writing effective user stories” di Thomas e Angela Hathaway.
Si tratta di un libro in formato digitale di dimensioni molto contenute (si legge in un soffio) che offre alcuni consigli di taglio molto pratico sulla formulazione delle user stories.
La formula delle user stories a cui fa riferimento il testo è quella classica, costituita da 3 elementi cardine: il punto di vista dell’utente (meglio sarebbe dire dello stakeholder), il risultato atteso e la motivazione per la quale viene realizzata l’attività in questione.
Ovvero: “In qualità di <utente> desidero che <risultato> così da <motivo>”.
La formula sembra facile, addirittura banale rispetto ai classici documenti di requisiti. Eppure nella sua essenzialità si rivela veramente efficace per descrivere ciò che dev’essere realizzato… a patto che… a patto che si rispettino queste 5 semplici regole!
Perseguire la semplicità
La user story deve indicare un solo risultato atteso, non di più!
Gli autori suggeriscono di evitare l’utilizzo di frasi composte e perifrasi, di star ben attenti alle espressioni che contengono congiunzioni quali “se”, “e” o “ma” ma anche “a meno che” ed “eccetto”, perché è molto probabile che – data la formulazione – nascondano più obiettivi o risultati.
In questo caso è sempre meglio separare più concetti in diverse storie, così da garantire maggiore facilità di elaborazione.
Esprimere il cosa, non il come
E’ fondamentale distinguere tra il cosa (il risultato atteso) ed il come (la soluzione adottata per raggiungere quel determinato risultato).
Il “come” è oggetto di elaborazione del team di sviluppo, non degli stakeholder.
Focalizzarsi sul risultato di business evitando di concentrarsi su come raggiungerlo ci consente di non arrivare a prospettare una soluzione troppo presto.
Pensiamo alla meta finale, non al viaggio.
Evitiamo premature decisioni tecnologiche e lasciamo al team l’onere e l’onore di individuare il modo più adeguato di soddisfare il bisogno.
Una user story che si focalizza sul “cosa” esprime maggior valore.
Per esperienza non è così semplice astrarsi dal “come”… meglio rileggere più volte ciò che è stato formulato.
Mantenere la rilevanza nei confronti del progetto
La user story è coerente con la finalità generale del progetto? E’ in linea con il project charter (se presente)? E’ sempre bene porsi questa domanda, perché troppo spesso nel backlog sopravvivono requisiti poco rilevanti o di nessuna utilità.
Una user story rilevante descrive funzionalità rilevanti per il progetto in termini di business, che non eccedono o sono al di fuori del suo scopo e che non creano effetti “a cascata”.
Mantenere solo le storie rilevanti fa risparmiare all’azienda tempo e denaro, oltre a sostenere la motivazione del team.
Evitare l’ambiguità
Dato che è difficile individuare formulazioni ambigue quando si è gli autori delle user story in prima persona gli autori ci suggeriscono di provare a cambiare prospettiva.
Tentiamo di metterci nei panni del lettore.
Proviamo a rileggere quanto abbiamo scritto in un contesto diverso, ad un’ora diversa del giorno.
Meglio ancora – se ne abbiamo la possibilità – chiediamo a qualcuno di riscrivere o riformulare la nostra user story mantenendone il significato ma utilizzando tutte parole diverse.
Questo trucco costringe l’interlocutore a pensare fuori dagli schemi.
Una volta che la “traduzione” è fatta verificheremo se le due storie coincidono nel significato. Se c’è aderenza la user story iniziale non presenta ambiguità; in caso contrario si disporrà di indicazioni preziose per riformulare la storia.
Il semplice atto di analizzare il modo in cui qualcun altro interpreta le nostre storie originarie offre preziosissime indicazioni.
Rendere misurabili i requisiti non funzionali
Non è sufficiente formulare il risultato che si vuole ottenere, dobbiamo poterlo esprimere in termini misurabili in modo da renderlo chiaro a qualsiasi tipo di pubblico.
Per sviluppare una soluzione che soddisfi i bisogni del richiedente gli sviluppatori hanno la necessità di avere requisiti funzionali e non funzionali espressi in termini misurabili (ricadono tra questi ultimi quelli relativi ad esempio a frequenza, urgenza, volumi, accuratezza, usabilità, flessibilità, scalabilità, affidabilità, ecc.).
Ricordiamoci che ciò che è oggettivamente misurabile può essere validata anche da terze parti.
Solo fornendo un requisito realmente misurabile saremo in grado – a lavoro terminato – di verificare il raggiungimento del nostro obiettivo.