---

Che cos'è un piano di rilascio Scrum? Potrebbe sorprenderti!

Il piano di rilascio visualizza la pianificazione generale di più Sprint, in questo esempio generalmente tra tre e dodici. Gli Sprint sono periodi di durata prestabilita; un Increment è un risultato utilizzabile e in uno Sprint se ne possono creare diversi.

Il piano diventa la guida che riflette le aspettative sul team riguardo a:

• Quali funzionalità verranno implementate,
• In quale ordine e quando.

È anche un riferimento per monitorare e controllare l'avanzamento. Funge da obiettivo per le distribuzioni effettive nei sistemi IT di produzione in due modi:

• Distribuzioni intermedie per creare valore prima del completamento del progetto. Coprono un sottoinsieme di requisiti concordati da Product Owner, cliente e stakeholder aziendali,
• Consegna finale che comprende tutte le esigenze e richieste di funzionalità note di cliente e stakeholder.

Prima di creare il piano, considera artefatti e informazioni seguenti:

• Uno Scrum Product Backlog stimato e ordinato per priorità,
• La velocità misurata del team (se si sta formando, la velocità viene stimata o ricavata da progetti simili precedenti),
• I criteri di successo imposti dai clienti come tempi, ambito e persone disponibili entro il budget.

Poiché è strettamente collegato al Product Backlog, lo Scrum Product Owner governa e mantiene il piano di rilascio.

In base a esigenze e priorità dei clienti, il piano soddisfa uno di questi tre obiettivi:

• Pianificazione del rilascio basata sulle funzionalità
• Pianificazione del rilascio basata sulla data
• Pianificazione del rilascio basata su funzionalità e data (La più comune)

Pianificazione del rilascio basata sulle funzionalità

Che cosa sappiamo: Velocità del team e funzionalità da consegnare.
Che cosa non sappiamo: Quanto tempo serve per consegnarle?

Per i piani basati sulle funzionalità (approfondisci Pianificazione dei rilasci Scrum), si divide la somma degli story point delle funzionalità richieste per la velocità. Si ottiene una prima previsione degli Sprint necessari per una consegna intermedia o finale. Arrotonda per eccesso a Sprint interi e verifica le ipotesi su ambito e velocità durante il lavoro. Prepariamo il piano di conseguenza.

Pianificazione del rilascio basata sulla data

Che cosa sappiamo: Velocità del team e data desiderata di consegna.
Che cosa non sappiamo: Quali funzionalità possiamo consegnare entro la scadenza?

Per i piani basati sulla data, moltiplichiamo la velocità per il numero di Sprint disponibili. Otteniamo il totale stimato degli story point consegnabili entro il rilascio e prepariamo il piano di conseguenza.

Pianificazione del rilascio basata su funzionalità e data

Che cosa sappiamo: Velocità del team, funzionalità e data desiderata di consegna.
Che cosa non sappiamo: Il team può consegnare le funzionalità richieste entro la scadenza?

Moltiplichiamo la velocità per gli Sprint disponibili, ottenendo il totale stimato degli story point consegnabili. Se supera la somma dei punti delle funzionalità del rilascio, la previsione attuale suggerisce che l'ambito rientri nei tempi; restano incertezza e cambiamenti.

Altrimenti, discutete compromessi su ambito, data e capacità. Aggiungere persone non aumenta automaticamente la velocità e può inizialmente rallentare il team mentre impara a collaborare. La vecchia indicazione di nove persone non è un limite attuale rigido: uno Scrum Team ne comprende generalmente 10 o meno. Un altro team può lavorare in parallelo se aumenta l'efficacia; sullo stesso prodotto condividono comunque Product Owner, Product Goal, Product Backlog e Definition of Done.

Come il Product Backlog, il piano non è statico: cambia durante il progetto mentre impariamo. User story nuove, rimosse o modificate e variazioni delle stime influiscono sui rilasci. Va quindi riesaminato e aggiornato regolarmente.