#Step 3: pianificare lo sprint [i requisiti]

Eccoci quindi al terzo appuntamento della nostra guida a Scrum in 10 semplici step.
Oggi ci occuperemo di come pianificare lo Sprint ed in particolare ci focalizzeremo sui pre-requisiti.
Se siete arrivati al nostro terzo appuntamento significa che avete già fatto ordine nel vostro backlog di progetto e avete già anche fatto una stima dello stesso.

Avanti tutta sullo sprint, allora!

Pianificazione dello Sprint – Primo Workshop

Come scrum master a questo punto devi organizzare il primo workshop di confronto tra tutti i soggetti coinvolti: assicurati che siano tutti presenti, ma veramente tutti.
Dall’analista allo sviluppatore, da chi eseguirà i Test a -naturalmente, poiché è imprescindibile- il Product Owner (link).
Lo scopo di questo primo workshop è appunto stilare un piano per il primo sprint, e per prima cosa dovrete -tutti insieme- stabilire una durata per lo sprint stesso.
Dovrebbero partecipare tutti gli elementi core del team. Forse il proprio tutti potrebbe portare a credere di dover coinvolgere anche gli stakeholder o le figure marginali.

Durata dello Sprint

Quanto deve durare, in media, uno Sprint?
Le linee Guida di scrum suggeriscono un mese, ma questo è uno dei punti più altamente personalizzabili da parte del team.
Perché? Perché fondamentalmente dipende molto dal livello di esperienza e “maturità” del team nella gestione agile dei propri progetti.
Un team già avviato, maturo diremmo, con processi interni di planning, testing e deplyment già ben consolidati troverà la durata di un mese probabilmente eterna.
Viceversa, un team ancora immaturo avrà bisogno di tutto il tempo necessario per prendere confidenza con la metodologia e gestire le diverse fasi di sviluppo e iterazione: 30 giorni saranno sentiti come assolutamente necessari.
Diciamo che una buona unità di misura di partenza può essere considerata la settimana: laddove ai team già “agili” ne basterà una, a quelli meno consolidati potranno servirne 2, 3 o anche tutte e 4.
La regola fondamentale comunque è che la durata dello sprint è una decisione che va presa insieme in maniera corale.
Per la durata, la chiave di lettura è da ricercare a cavallo tra la disponibilità del cliente (ogni quanto riesco a mostrargli e rilasciargli gli avanzamenti?) e la modularità del progetto (ogni quanto tempo riesco ad avere un modulo, una funzionalità, ecc, completo, mostrabile o addirittura rilasciabile?
La lunghezza ideale di una sprint si calibra su questi due parametri temporali.

Rispetta e tieni fissa la durata stabilita

Al di là della durata stabilita il punto fondamentale che è necessario tener saldo è la costanza di questa misura di tempo.
La costanza è molto più importante della durata in sé: sapete perché? Perché sarà la ripetizione del medesimo intervallo di tempo a:

– Dare ritmo al lavoro
– Farvi capire quanti punti del backlog stanno mediamente all’interno di uno sprint, ovvero la velocità del vostro team
– Farvi avviare su una strada e di lavoro coerente e costante

A questo punto potete permettervi di pianificare già tutti i successivi workshop prima dell’inizio di ogni nuovo sprint.

Fissate l’obiettivo dello sprint

Con dei tempi alla mano, potete ora fissare degli obiettivi ragionevoli da raggiungere entro i termini stabiliti.
Guardate chiaramente alla parte alta del backlog: quali sono i punti che pensate di poter includere? Potete sintetizzarli in un obiettivo comune o comunque selezionarne una lista precisa?
Quello è il vostro obiettivo: e dovete stabilirlo insieme, non dev’essere mai una decisione calata dall’alto.
Riservatevi sempre anche i cosiddetti stretch tasks: punti in più dal backlog, che potrete affrontare solo nel caso ottimistico (ma non impossibile) di finire tutti i punti inseriti nell’obiettivo dello sprint prima del suo termine.
Nel migliore dei casi non rimarrete con persone inattive sul progetto.
Nel peggiore avrete comunque -al secondo sprint- una lista di punti già pre-stabiliti.
Attenzione però: gli stretch tasks non fanno parte in sé e per sé dell’obiettivo dello sprint, ed il Product Owner non deve aspettarsi di vederli terminati entro il suo termine.
Sono per l’appunto dei punti in più, che si aggiungono all’obiettivo ma che non ne determinano il fallimento se non vengono implementati entro lo sprint.

I requisiti dello Sprint: le user story

Ora prendete ogni singolo punto del backlog che avete inserito in questo primo Sprint.
Analizzateli uno per uno, col team al completo.
Per ogni punto dovete arrivare ad individuare scopo, metodo di esecuzione ed eventuali criticità/soluzioni.
Fate uso di una lavagna magnetica o della tipica lavagna a fogli mobili del metodo agile: il contetto fondamentale è annotare per ogni punto del backlog i requisiti specifici.
Non serve ripetere (ma lo facciamo ;)) che sono tutte azioni che svolgerete all’interno del workshop come team, proprio per avviare lo sprint.
Scrivete i requisiti in maniera leggibile, comunicativa, in modo che non ci siano ripensamenti o dubbi in corso di lavorazione.
Un altro importante consiglio è quello di utilizzare delle User Story.
Ovvero, per ogni punto, tracciare i potenziali casi d’uso:

Come [tipo utente A] voglio poter [compiere un’azione], per ottenere [un certo risultato X]
Come [tipo utente B] voglio poter [compiere un’azione], per ottenere [un certo risultato Y]
etc etc.

Anche le story dovranno essere aggiunte sulla lavagna in associazione a ciascun punto e ai suoi singoli requisiti.
La lavagna vi mostrerà alla fine la mappa delle azioni e degli obiettivi da intraprendere punto per punto.

Step #1: Tieni in ordine il tuo Backlog di progetto
Step #2: Come fare la stima del tuo backlog di progetto

Step #4: Come pianificare lo Sprint – I task
Step #5: Come creare un ambiente di lavoro collaborativo
Step #6: Come implementare lo Sprint con Scrum
Step #7: Standup e… fai sentire la tua voce!
Step #8: Traccia i progressi con un diagramma quotidiano
Step #9: Consegna in tempo!
Step #10: Rivedi, rifletti, ripeti.