Mappa mentale per suddividere le user stories

Story-Splitting-Flowchart-Thumbnail

Come orientarsi tra i tanti criteri per dividere user stories di grandi dimensioni?
Mi riprometto di scrivere un post più approfondito su questo tema, ma nel frattempo ho scovato in rete questa mappa visuale che sintetizza a colpo d’occhio le alternative più comuni.
Per chi, come me, ama schematizzare informazioni e processi è un piccolo capolavoro da condividere.

Fonte: Agile For All – “New story splitting resource”

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 (è un grande vantaggio anche per il Product Owner!).
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 o 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 future conversazioni.

ValuableDi valore
In un mondo ideate 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: gli sviluppatori non conoscono perfettamente il dominio e non si sentono confidenti nel dare una stima iniziale, hanno una conoscenza parziale della tecnologia da utilizzare 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 (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 grooming, quando potrebbero sorgere problemi nella stima.
Anche in questo caso bisognerà splittare le storie tanto grosse da non poter entrare in uno sprint (di solito sono epiche nascoste!) o combinare più user stories affinche 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.

 

L’80/20 applicato al Backlog

Cosa succederebbe se provassimo ad applicare il principio di Pareto (la famosa regola dell’80/20) al nostro backlog? E’ questa la riflessione a cui ci invita Stefan Haas – Agile coach con molti anni di esperienza sul campo – in uno degli ultimi articoli del suo blog.

Siamo in grado di individuare quel 20% di funzionalità che producono l’80% della soddisfazione dei nostri utenti finali? Abbiamo idea di quali siano l’80% dei requisiti che producono scarso o nullo valore per i nostri clienti?
Al di là della provocazione, sappiamo per esperienza che non tutto ciò che è contenuto nel backlog è realmente di valore per l’utente e – nonostante ciò – è nostro compito trovare spazio anche per attività – ad esempio – di aggiornamento dei sistemi, business intelligence o per adeguamenti di legge.

E’ in ogni caso interessante fermarsi a riflettere sull’opportunità di individuare ed avere sempre ben presente quel 20% di funzionalità che rappresentano il cuore dei nostri prodotti, quel 20% di un’epica (poi suddivisa in user stories) che ne rappresenta l’essenza, quel 20% di attività quotidiane del team che produrrà il maggior valore nel corso dell’iterazione.

Il principio può essere infatti applicato a tutti i livelli: al prodotto nel suo insieme, alle epiche, alle singole user stories o – segmentando ancora di più – ai task.
La sfida è individuare quel 20% critico del backlog in grado di produrre l’80% del valore finale e  mettere in priorità queste attività focalizzando l’impegno del team soprattutto su di esse.