Il PI Planning è l'evento a cadenza fissa dello Scaled Agile Framework (SAFe) in cui tutti i team di un Agile Release Train (ART) pianificano insieme il successivo Planning Interval, in presenza o da remoto. Dura in genere due giorni, si ripete ogni 8-12 settimane e si chiude con i PI objectives condivisi dai team e con l'ART planning board, che mostra date di rilascio e dipendenze.
WWG ha organizzato il suo primo PI Planning completamente remoto a dicembre 2020, con i team sviluppo, marketing, vendite e post-vendita collegati in videoconferenza. Questa guida conserva quello che abbiamo imparato allora e lo aggiorna alla terminologia di SAFe 6.0: cos'è il PI Planning, chi partecipa, l'agenda dei due giorni, rischi e voto di fiducia, la differenza con lo sprint planning e come gestirlo con team ibridi.
TL;DR / In sintesi
- Il PI Planning allinea tutti i team di un ART su un unico piano per il successivo Planning Interval, di solito lungo 8-12 settimane.
- Lo facilita il Release Train Engineer; partecipano Business Owner, Product Management, architetti e tutti gli Agile Team.
- L'agenda standard dura due giorni: contesto di business e visione, due sessioni di lavoro dei team, revisione del management, revisione finale, rischi e voto di fiducia.
- I due risultati sono i PI objectives confermati dai team, con il valore di business assegnato dai Business Owner, e l'ART planning board.
- Il PI Planning remoto o ibrido funziona se la preparazione è accurata e gli strumenti digitali sono pronti prima del primo giorno.
Cos'è il PI Planning nello Scaled Agile Framework?
Il PI Planning è l'evento in cui un intero Agile Release Train pianifica insieme il successivo Planning Interval (PI). In SAFe 6.0 la sigla PI indica il Planning Interval, in precedenza chiamato Program Increment. SAFe lo considera essenziale: "se non lo fai, non stai facendo SAFe". Dura in genere due giorni e si ripete ogni 8-12 settimane.
Un PI è un intervallo a cadenza fissa in cui gli Agile Release Train generano valore per i clienti in linea con i propri PI objectives. Lo schema più comune prevede quattro iterazioni di sviluppo seguite da un'iterazione di Innovation and Planning (IP). Il PI Planning si svolge proprio durante l'iterazione IP, così non sottrae capacità alle iterazioni di sviluppo.
L'evento applica uno dei principi del Manifesto Agile: la conversazione faccia a faccia è il modo più efficiente ed efficace per comunicare con il team e all'interno del team. Chi fa il lavoro pianifica il lavoro, tutti insieme.
"La resistenza al cambiamento è il più grande ostacolo da superare"
Chris Paine
Perché il PI Planning è importante per un'azienda che cresce?
Il PI Planning è importante perché trasforma tanti piani separati in un unico piano condiviso che tutti hanno visto. Allinea lo sviluppo agli obiettivi di business, fa emergere le dipendenze tra team prima che causino ritardi, adatta la domanda alla capacità reale e accelera le decisioni, perché business owner e team sono presenti nello stesso momento.
La trasformazione lean si basa su metodi e strumenti, ma la sua efficacia dipende dalle relazioni tra le persone in azienda. La resistenza al cambiamento è normale: le persone devono vedere sparire sprechi e tempi morti prima che un nuovo modo di lavorare si consolidi.
Per WWG la prova è arrivata nel 2020. Da anni spingevamo i clienti dei nostri progetti di sviluppo software su misura ad adottare un framework agile; organizzare un PI Planning al nostro interno è stato il momento di passare dalla teoria alla pratica. Se i concetti di base sono nuovi, parti dai principi della metodologia agile, su cui SAFe è costruito.
Chi partecipa al PI Planning?
Partecipa l'intero Agile Release Train. Il Release Train Engineer (RTE) facilita l'evento, i Business Owner presentano il contesto e assegnano valore agli obiettivi, il Product Management presenta visione e priorità, i System e Solution Architect illustrano la visione architetturale e ogni Agile Team pianifica il proprio lavoro, con il supporto del System Team.
- Release Train Engineer (RTE): programma e facilita l'evento, presenta il processo di pianificazione e guida la revisione dei rischi e la retrospettiva.
- Business Owner: descrivono lo stato del business, rivedono le bozze dei piani e assegnano il valore di business ai PI objectives di ogni team.
- Product Management: presenta la visione del prodotto o della soluzione, di solito come le prime dieci funzionalità in arrivo.
- System Architect: presenta la visione architetturale ed eventuali cambiamenti nelle pratiche di sviluppo.
- Agile Team: stimano la capacità, pianificano iterazione per iterazione, individuano rischi e dipendenze e si impegnano sugli obiettivi.
Quali sono gli input e gli output del PI Planning?
Gli input sono il contesto di business, la roadmap e la visione, e le funzionalità a priorità più alta dell'ART backlog. Gli output sono due: i PI objectives confermati, cioè obiettivi SMART per ogni team con il valore di business assegnato dai Business Owner, e l'ART planning board, con date di rilascio, dipendenze e milestone.
L'ART planning board si chiamava program board nelle versioni precedenti di SAFe. I team definiscono anche obiettivi non vincolanti (uncommitted objectives): obiettivi inseriti nel piano ma non garantiti perché presentano troppe incognite. Non sono lavoro extra per il tempo libero; rendono il piano più affidabile e avvisano per tempo il management.
Dopo l'evento, l'RTE e gli stakeholder riassumono gli obiettivi dei team negli ART PI objectives, usati per comunicare all'esterno e seguire i progressi. Se l'azienda lavora già con gli OKR, il collegamento avviene qui: leggi cosa non sono gli OKR per mantenerli coerenti.
Com'è organizzata l'agenda dei due giorni?
L'agenda standard dura due giorni. Il primo giorno fissa il contesto e produce le bozze dei piani, che il management rivede a fine giornata. Il secondo giorno corregge i piani, chiude gli obiettivi, li rivede tutti insieme, affronta i rischi, svolge il voto di fiducia e termina con una retrospettiva. Con team su più fusi orari si può allungare.
| Giorno | Sessione | Cosa succede | Chi la guida |
|---|---|---|---|
| 1 | Contesto di business | Stato attuale del business e visione del portfolio | Business Owner o dirigente |
| 1 | Visione di prodotto/soluzione | Principali funzionalità in arrivo e cambiamenti dall'ultimo PI | Product Management |
| 1 | Visione architetturale e pratiche di sviluppo | Architettura e cambiamenti come test automatici o CI/CD | System Architect, responsabile sviluppo |
| 1 | Contesto della pianificazione | Processo di pianificazione e risultati attesi | RTE |
| 1 | Sessioni dei team #1 | Capacità per iterazione, bozze dei piani, rischi, dipendenze, bozza degli obiettivi | Agile Team |
| 1 | Revisione delle bozze | I team presentano capacità e carico, obiettivi, rischi e dipendenze | Team, con i Business Owner |
| 1 | Revisione del management | Si adattano ambito, persone e risorse per obiettivi raggiungibili | Management, RTE |
| 2 | Aggiustamenti | Il management presenta le modifiche ad ambito, persone e risorse | Management |
| 2 | Sessioni dei team #2 | Obiettivi finali; i Business Owner assegnano il valore di business | Agile Team, Business Owner |
| 2 | Revisione finale dei piani | Ogni team presenta piano, rischi e impedimenti | Agile Team |
| 2 | Rischi dell'ART | I rischi vengono discussi apertamente e classificati con ROAM | RTE |
| 2 | Voto di fiducia e revisione del piano | Voto fist of five; si rivede il piano finché la fiducia è alta | Tutti i team |
| 2 | Retrospettiva | Cosa ha funzionato, cosa no, cosa migliorare | RTE |
Un momento del PI Planning WWG di dicembre 2020
Come si gestiscono i rischi durante il PI Planning?
I rischi vengono raccolti da ogni team durante la revisione finale dei piani e discussi apertamente davanti a tutto il treno. Ognuno viene poi assegnato a una delle quattro categorie ROAM: risolto, preso in carico, accettato o mitigato. Lo scopo è evitare che qualcuno lasci l'evento con un rischio nascosto.
- Risolto (Resolved): i team concordano che il rischio non è più un problema.
- Preso in carico (Owned): qualcuno se ne assume la responsabilità, perché non può essere risolto durante la pianificazione.
- Accettato (Accepted): alcuni rischi sono semplicemente fatti o potenziali problemi da comprendere e accettare.
- Mitigato (Mitigated): i team individuano un piano per ridurne l'impatto.
I rischi che i team non possono risolvere da soli vengono affrontati in un contesto manageriale più ampio. Nella nostra esperienza ogni rischio ha bisogno anche di un breve testo di spiegazione, perché un post-it di una riga raramente basta.
Come funziona il voto di fiducia?
Una volta affrontati i rischi, ogni team vota la propria fiducia nel raggiungere i PI objectives alzando da una a cinque dita, il "fist of five". Se la media è tre o più, il management accetta l'impegno; se è inferiore a tre, il team rivede il piano. Poi il voto si ripete per l'intero ART sul piano complessivo.
Chi vota due dita o meno viene invitato a spiegare il perché. I suoi dubbi possono diventare nuovi rischi, richiedere una ripianificazione o semplicemente fornire informazioni.
Se serve, segue la revisione del piano, una delle poche occasioni in cui l'impegno conta più del rispetto dei tempi. Nel nostro evento del 2020 il team marketing WWG ha usato questa fase per definire le risorse di ogni obiettivo, sia le persone sia tutto ciò che serve a supportarle.
Un altro momento del PI Planning del team marketing WWG
In cosa il PI Planning è diverso dallo sprint planning?
Lo sprint planning è l'evento di un solo team per pianificare uno sprint di un mese o meno, e dura al massimo otto ore per uno sprint di un mese. Il PI Planning riunisce tutti i team del treno per circa due giorni e pianifica un intero Planning Interval, con dipendenze e valore di business.
I due eventi lavorano a livelli diversi. Il PI Planning fissa gli obiettivi e il piano tra team per l'intervallo, poi ogni team svolge l'iteration planning all'inizio di ogni iterazione per dettagliare il lavoro.
Come si organizza il PI Planning con team remoti e ibridi?
Il PI Planning remoto o ibrido funziona se la preparazione è fatta per tempo e tutti i team usano gli stessi strumenti digitali. SAFe riconosce che la pianificazione virtuale, in tempo reale e in contemporanea, si è dimostrata efficace quando la presenza fisica non è possibile. Servono una board condivisa, video affidabile e un modo digitale per votare.
A dicembre 2020 WWG ha svolto tutto in videoconferenza. Abbiamo usato Jira per epic, story, task e sprint; Big Agile, integrato con più progetti Jira, come board condivisa per obiettivi, sprint e dipendenze; Microsoft Teams per le chiamate e un canale per ogni team; e Voting Poker per il voto di fiducia online, una vera stima agile. Oggi gli stessi ruoli sono spesso coperti da Jira Align, che supporta SAFe tra altri framework di scala, e da lavagne online come Miro.
Cosa ha funzionato: con una buona pre-pianificazione l'evento remoto è stato efficiente quanto uno in presenza, con meno distrazioni e un documento master con l'intero ambito e le dipendenze. Non ci sono state spese di viaggio o alloggio, e il lavoro in corso in eccesso si è ridotto.
Ce l'abbiamo fatta! La nostra prima pianificazione PI distribuita e completamente remota. È un addio ai post-it o solo un arrivederci?
Cosa è stato più difficile: il coordinamento cresce con ogni team coinvolto (noi ne avevamo quattro) e i team con molte dipendenze sono difficili da allineare. Bloccare tutti i team per due giorni ha un costo, le conversazioni informali spariscono e il voto di fiducia è più complicato da remoto. Le persone tendono anche a seguire lo schermo in modo passivo, quindi la facilitazione deve sollecitare la partecipazione.
Cosa deve contenere una checklist per il PI Planning?
Una checklist per il PI Planning copre tre tipi di preparazione: organizzativa (persone e decisori giusti disponibili), di contenuto (contesto di business, visione e funzionalità prioritarie pronte) e logistica (sale o spazi virtuali, strumenti e accessi). La preparazione è ciò da cui dipendono i due giorni, quindi inizia settimane prima.
- Preparazione organizzativa: Business Owner confermati per entrambi i giorni, RTE assegnato, team e capacità noti.
- Preparazione dei contenuti: contesto di business e visione pronti, funzionalità principali dell'ART backlog prioritizzate e comprese, visione architetturale pronta.
- Preparazione logistica: sale o link video, una board condivisa, modelli per i PI objectives e un sistema di voto.
- Dopo l'evento: inserire obiettivi e story nello strumento di pianificazione, confermare il calendario degli eventi di team e di ART e pubblicare gli ART PI objectives.
Impostare questa cadenza la prima volta è spesso la parte più difficile. Il servizio WWG di implementazione del processo di sviluppo software aiuta i team a introdurre pratiche di pianificazione agile adatte alle loro dimensioni.
Per capire come introdurre il PI Planning nei tuoi team, scrivici a info@wwg.it.
Fonti
- Scaled Agile, Inc., PI Planning — https://framework.scaledagile.com/pi-planning/
- Scaled Agile, Inc., PI Planning, articolo completo archiviato il 7 giugno 2024 — https://web.archive.org/web/20240607154138/https://scaledagileframework.com/pi-planning/
- Scaled Agile, Inc., Planning Interval (PI) — https://framework.scaledagile.com/planning-interval/
- Manifesto Agile, Principi sottostanti al Manifesto Agile — https://agilemanifesto.org/iso/it/principles.html
- Ken Schwaber e Jeff Sutherland, The Scrum Guide (2020) — https://scrumguides.org/scrum-guide.html
- Agile Way, Planning poker, stima agile dei requisiti — https://www.agileway.it/planning-poker-stima-agile-requisiti
- Atlassian, Jira Align — https://www.atlassian.com/software/jira-align
FAQ
Domande frequenti
Un Planning Interval dura in genere 8-12 settimane. Lo schema più comune prevede quattro iterazioni di sviluppo seguite da un'iterazione di Innovation and Planning, durante la quale si svolge il PI Planning successivo. La durata esatta la sceglie ogni treno, ma deve restare costante perché la pianificazione segua una cadenza prevedibile.
Gli obiettivi non vincolanti sono obiettivi che un team inserisce nel piano senza impegnarsi a raggiungerli, perché presentano troppe incognite o rischi. Non sono lavoro extra per il tempo libero. Aumentano l'affidabilità del piano e segnalano per tempo al management gli obiettivi che il treno potrebbe non riuscire a consegnare.
Dopo l'evento i team inseriscono PI objectives e story nello strumento di pianificazione e confermano il calendario degli eventi di team e di treno. Il Release Train Engineer e gli stakeholder riuniscono poi gli obiettivi dei team negli ART PI objectives, usati per comunicare i progressi all'esterno e seguire la consegna durante l'intervallo.
Sì, qualsiasi gruppo di team con dipendenze condivise può usarne il formato senza tutti i ruoli e le pratiche di SAFe, anche se SAFe considera il PI Planning parte del framework completo. Vanno mantenuti gli elementi centrali: contesto di business condiviso, sessioni dei team, dipendenze visibili, revisione aperta dei rischi e voto di fiducia.
