Le buone user stories sono INVEST

L’acronimo INVEST creato da Bill Wake nel 2003 è un trucco che i Product Owner possono utilizzare per ricordare le qualità di una buona user story.
Cosa significano le iniziali? Semplicissimo!

IndipendentIndipendenti

Quando le user stories non sono indipendenti tra loro possono produrre stime non corrette, vincoli di implementazione e potenziali rigidità nella pianificazione dei rilasci.
L’ideale è segmentare le storie in modo tale che possano essere implementate secondo qualsiasi ordine (qui ho parlato dei criteri di suddivisione).

Quando ci troviamo di fronte a delle dipendenze possiamo provare alcune soluzioni alternative:

  • combinare insieme le storie interessate (purché si possano concludere in uno sprint)
  • suddividerle in una maniera differente
  • segmentarle in storie più piccole.

Quando proprio non è possibile scrivere user stories indipendenti è meglio definire un ordine di implementazione e fornire stime differenti per la prima storia e le successive (ad esempio 3 punti per la prima e 1 per le successive).

NegotiableNegoziabili

Una delle qualità più apprezzabili delle user stories – dal mio punto di vista – sta nel fatto di non essere contratti scritti nella pietra una volta per sempre.
Le storie sono brevi descrizioni delle funzionalità desiderate. Catturano l’essenza di una richiesta, non le specifiche di dettaglio.

In Scrum la definizione dell’ambito di una storia (il cosidetto “scope”) non è come nel processo waterfall appannaggio esclusivo del project manager; i dettagli sono negoziabili e vengono negoziati perché emergono dai dialoghi tra il cliente, il product owner e il team.

La user story è un invito a conversazioni future.

ValuableDi valore

In un mondo ideale tutte le storie sono di valore per l’utente finale; nella realtà non è sempre così, ma è utile tenere a mente questa aspirazione e interrogarsi sul vero beneficiario della user story (a volte può essere il cliente che paga lo sviluppo software, il committente interno, lo sponsor, il reparto vendite o altri tipi di stakeholder).

L’importante è evitare di perdere tempo (e soldi) in storie che non solo di valore per nessuno e provare a ricercare benefici “spendibili” anche nelle storie tecniche.

EstimableStimabili

Dal momento che Scrum prevede iterazioni time-boxed che siano autoconclusive, la stima di una storia e del tempo necessario per produrla è un’attività fondamentale nel team.
Quando la valutazione risulta difficile siamo solitamente di fronte ad uno di questi problemi:

  1. gli sviluppatori non conoscono perfettamente il dominio e non si sentono confidenti nel dare una stima iniziale
  2. hanno una conoscenza parziale della tecnologia da utilizzare
  3. oppure le storie risultano troppo grandi o poco chiare.

Nei primi due casi si può cominciare a programmare un’attività di analisi da parte del team (una spike) per arrivare a una stima sufficiente dell’ordine di grandezza delle attività; negli altri è il Product Owner che deve farsi carico di segmentare di più le storie e dettagliare maggiormente i criteri di accettazione.

Size appropriately or SmallDella giusta dimensione

La dimensione giusta è “quanto basta”… e come nelle ricette di cucina si migliora con la pratica, perché non è sempre evidente a cosa corrisponda il fatidico q.b.
Una cosa è certa: se le storie sono troppo piccole o troppo grandi ve ne accorgerete!
Il team non mancherà di farvelo notare già in fase di refinement, quando potrebbero sorgere problemi nella stima.
Anche in questo caso bisognerà dividere le storie tanto grosse da non poter entrare in uno sprint (di solito sono epiche nascoste!) o combinare più user stories affinchè l’effort complessivo comporti almeno una mezza giornata di lavoro.

TestableTestabili

Al termine di ogni sprint vengono rilasciate delle funzionalità che sono “done” e dev’essere possibile dimostrare al cliente finale questo stato “finito”.
Ecco perché nella user stories non possono mancare criteri di accettazione effettivamente misurabili, ognuno dei quali possa poi essere misurato attraverso i test.
Quando i test passano (proviamo ad automatizzarne il più possibile) dimostriamo che le storie sono complete.

INVEST!

Ovvero user stories indipendenti, negoziabili, di valore, stimabili, della giusta dimensione (né troppo piccole né troppo grandi) e testabili.

L’articolo originale di Wax si intitola INVEST in Good Stories and SMART Tasks.

User stories efficaci: 5 regole per non sbagliare

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.