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.