Sprint Zero
Sempre piu team lavorano con uno "Sprint Zero". Ma e davvero una buona idea?
Uno Sprint Zero viene utilizzato principalmente quando determinate cose devono essere completate prima dell'effettivo inizio del progetto. Forse bisogna ancora formare un team o procurare l'hardware. In alcuni progetti viene addirittura richiesto un Backlog separato per questo Sprint.
Uno dei problemi principali di uno Sprint Zero e che vengono applicate regole diverse per un determinato Sprint o un determinato tipo di Sprint. Ad esempio, con uno Sprint Zero l'obiettivo del team non e piu quello di ottenere qualcosa di potenzialmente consegnabile alla fine. Come potrebbe nascere qualcosa di potenzialmente consegnabile, se l'obiettivo dello Sprint e quello di formare un team per lo sviluppo del prodotto?
Sprint 0 vs. pre-progetto
A mio parere, la maggior parte delle cose considerate un argomento a favore di uno Sprint Zero appartiene piuttosto a un "progetto prima del progetto". Prima di un progetto di sviluppo esiste spesso un progetto separato in cui si decide se debba esistere un progetto di sviluppo. Prima che un'azienda inizi un nuovo grande progetto, si dovrebbe sempre prima riflettere se questo progetto debba essere realizzato o meno.
La decisione pro o contro lo Sprint Zero puo essere considerata come un progetto a se stante.
Poiche Scrum rappresenta un buon framework per il project management, puo essere utilizzato anche per il progetto-prima-del-progetto. In questo progetto-prima-del-progetto, i membri del team gia definiti (o anche solo il futuro Product Owner) possono creare un primo Product Backlog, trovare i membri del team, creare i prerequisiti tecnici ecc.
Trovo sensato considerare questi lavori come un progetto a se stante, perche un singolo Sprint spesso non e sufficiente. Come chiamerebbe un team il suo secondo Sprint, se lo Sprint 0 non fosse sufficiente? Sprint 0,5?
A questo punto bisogna considerare alcune cose:
Mantieni il progetto-prima-del-progetto il piu semplice possibile. La maggior parte dei progetti di sviluppo non ha nemmeno bisogno di un ulteriore progetto preliminare.
Attieniti ai principi di Scrum. Nell'esecuzione di un progetto-prima-del-progetto non nasce nulla di potenzialmente consegnabile. E questo va bene. Ma ricorda sempre perche e un principio cosi centrale di Scrum ottenere qualcosa di potenzialmente consegnabile alla fine. E dovresti tenerne conto anche nel progetto-prima-del-progetto.
