User story e pianificazione dell'iterazione

Una user story è una breve descrizione di qualcosa di cui un utente ha bisogno, scritta dal suo punto di vista. La pianificazione dell’iterazione è il modo in cui un team decide su quali storie lavorerà nel prossimo blocco di tempo. Molti team chiamano questo blocco sprint e la riunione sprint planning; East Agile Tracker li chiama iterazioni e pianificazione dell’iterazione.

Cos’è una user story

Il modello più comune è:

Come [tipo di utente], voglio [una capacità], così da [un beneficio].

Per esempio: Come project manager, voglio vedere quali storie sono bloccate, così da sbloccarle prima che finisca l’iterazione.

Il modello indica chi ne beneficia, di cosa ha bisogno e perché. Il “perché” permette al team di trovare un modo più semplice per offrire lo stesso beneficio. Una storia è un segnaposto per una conversazione, non una specifica completa: i dettagli si definiscono tra chi chiede e chi costruisce.

INVEST: la storia è pronta?

INVEST è una checklist per una storia ben formata:

• Independent (indipendente) — può essere costruita e consegnata da sola.
• Negotiable (negoziabile) — i dettagli sono aperti alla discussione.
• Valuable (di valore) — offre qualcosa che importa a un utente o a un cliente.
• Estimable (stimabile) — il team la capisce abbastanza da dimensionarla.
• Small (piccola) — sta comodamente in un’iterazione.
• Testable (verificabile) — c’è un modo chiaro per capire che è fatta.

Criteri di accettazione

I criteri di accettazione stabiliscono cosa deve essere vero perché la storia conti come fatta. Scriverli nella forma Given / When / Then trasforma ciascuno in un test di accettazione:

Given una storia con un blocker non risolto, when apro la colonna Blocked, then la storia compare lì.

I criteri si concordano prima che inizi il lavoro, così il team e la persona che accetta la storia condividono la stessa definizione di fatto.

Pianificazione dell’iterazione

La pianificazione dell’iterazione risponde a una sola domanda: su cosa lavoreremo in questa iterazione? Servono tre input:

1. Un backlog ordinato — storie classificate per priorità, con quelle in cima pronte (conformi a INVEST, con criteri di accettazione).
2. Stime — ogni storia candidata dimensionata in story point.
3. Velocity — quanti punti il team completa per iterazione. Vedi Cos’è la velocity?.

Il team prende storie dalla cima del backlog finché il totale non raggiunge la sua velocity. Prenderne di più presuppone che il team lavori all’improvviso più velocemente; prenderne di meno lascia capacità inutilizzata.

Come funziona in East Agile Tracker

• Le storie sono di quattro tipi: feature, bug, chore e release. Per default solo le feature prendono punti. Vedi Storie.
• I criteri di accettazione vanno nella descrizione. Non c’è un campo separato; i criteri appartengono alla descrizione prima che la storia venga avviata. Quando una storia è delivered, il product owner la accetta o la rifiuta rispetto a quei criteri. Vedi la macchina a stati e il ciclo di accettazione.
• Il backlog è un unico elenco rigorosamente ordinato, che proietta le iterazioni future a partire dalla velocity, tre o quattro in avanti, segnalando ogni gruppo che supera la velocity. Vedi Iterazioni.
• La pianificazione dell’iterazione è in gran parte automatica. Con auto-plan iterations attivo (il default), l’iterazione corrente si riempie fino alla tua velocity; portarci dentro una nuova storia rimanda quella a priorità più bassa in cima al Backlog. I team che si impegnano su uno scope fisso, in stile Scrum, possono disattivare l’auto-plan e pianificare quanto vogliono, con un contatore che diventa rosso oltre la velocity. Vedi Pianificare un’iterazione.
• Creare una storia apre un composer per titolo, descrizione, tipo, stima e owner. Vedi Creare una storia.

Per approfondire

• Cosa sono gli story point? — dimensionare le storie.
• Cos’è la velocity? — il lato della capacità nella pianificazione.
• eXtreme Programming — da dove vengono le user story e il Planning Game.