PI Planning in 60 seconden
- Wat het is: een op cadans gebaseerd evenement waarin alle teams van een Agile Release Train (ART) samen het volgende Planning Interval plannen.[1]
- Hoe vaak: elke 8 tot 12 weken, meestal als tweedaags evenement onder leiding van de Release Train Engineer (RTE).[1]
- Wie nemen er deel: de hele ART, doorgaans 50 tot 125 mensen, plus Business Owners en andere stakeholders.[2]
- Wat het oplevert: toegezegde PI Objectives voor elk team en een ART Planning Board met de opleverdata van features, teamoverstijgende afhankelijkheden en mijlpalen.[3]
- Remote werkt: volgens SAFe is virtueel plannen effectief wanneer fysieke aanwezigheid niet mogelijk is, mits de hele ART deelneemt.[1]
- Naamgeving: sinds SAFe 6.0 staat PI voor Planning Interval. Voorheen heette het Program Increment, en het program board heet nu het ART Planning Board.[4]
Wat is PI Planning?
PI Planning is een op cadans gebaseerd evenement binnen het Scaled Agile Framework (SAFe) waarin alle teams van een Agile Release Train samenkomen, op locatie of online, om zich te richten op een gedeelde missie en visie en om het werk voor de komende 8 tot 12 weken te plannen. Het duurt doorgaans twee dagen en wordt geleid door de Release Train Engineer.[1]
De officiële SAFe-definitie is kort: PI Planning is "een op cadans gebaseerd evenement voor de hele ART dat teams en stakeholders afstemt op een gedeelde missie en visie."[1] In de praktijk is het het enige moment in het kwartaal waarop de mensen die bepalen wat er gebouwd wordt, de mensen die het bouwen en de mensen die ervoor betalen op hetzelfde moment naar hetzelfde plan kijken.
Een Planning Interval (PI) is een timebox van 8 tot 12 weken. Een veelgebruikt patroon is vier of vijf ontwikkeliteraties, gevolgd door één Innovation and Planning (IP)-iteratie, al presenteert SAFe dat patroon als suggestie en niet als regel.[4] De PI Planning zelf vindt plaats in de IP-iteratie, zodat teams het volgende interval niet hoeven te plannen terwijl ze het huidige nog opleveren.[5]
PI Planning staat ook bekend als Program Increment planning (de SAFe-naam van vóór versie 6.0, die nog steeds wordt gebruikt in de documentatie van Atlassian en Microsoft[6]), kwartaalplanning of big room planning. De namen verschillen. Het evenement is hetzelfde.
Welke versie van SAFe volgt deze gids?
Deze gids volgt SAFe 6.0, nog altijd de meest recente genummerde versie van het framework.[7] Scaled Agile werkt SAFe tegenwoordig doorlopend bij en introduceerde in juni 2026 AI-Native SAFe als operating model dat op hetzelfde fundament is gebouwd.[8] Niets in die updates verandert het doel of de opzet van PI Planning zoals die hier wordt beschreven.
| Oudere term | Huidige SAFe-term |
|---|---|
| Program Increment (PI) | Planning Interval (PI)[4] |
| Program board | ART Planning Board[3] |
| Scrum of Scrums | Coach Sync. Samen met de PO Sync vormt deze de ART Sync[9] |
| Program backlog, program Kanban | ART Backlog, ART Kanban |
| Program predictability measure | ART Predictability Measure[3] |
Waarom is PI Planning belangrijk?
PI Planning is belangrijk omdat het tientallen losse teamplannen vervangt door één plan dat de hele Agile Release Train heeft gezien, kritisch heeft getoetst en heeft toegezegd. Afhankelijkheden, capaciteitstekorten en risico's komen in twee dagen van gesprekken aan het licht, in plaats van weken later als gemiste deadlines.
Eén agile team kan een sprint in een middag plannen. Zodra het werk zich over vijf, acht of twaalf teams verspreidt, zitten de lastige problemen niet langer binnen een team. Ze zitten tussen de teams: het ene team heeft een API nodig die een ander team niet heeft ingepland, een gedeeld platformteam is dubbel volgeboekt, een compliance-mijlpaal is bij slechts één persoon bekend.
Het Agile Manifesto stelt dat een gesprek van persoon tot persoon de meest efficiënte en effectieve manier is om informatie te delen met en binnen een team[10], en dat principe is de reden dat het evenement bestaat. PI Planning geeft dat gesprek een tijdslimiet en een structuur voor de hele train. De opbrengsten die teams doorgaans noemen zijn:
- Afstemming. Elk team hoort uit de eerste hand dezelfde businesscontext, productvisie en architectuurrichting.
- Zichtbare afhankelijkheden. Verbanden tussen teams worden afgesproken en op een gedeeld board geplaatst terwijl beide teams aanwezig zijn.
- Realistische belasting. Teams plannen op basis van hun eigen capaciteit, zodat het plan weergeeft wat haalbaar is en niet waarop werd gehoopt.
- Snellere besluiten. Afwegingen over scope worden ter plekke gemaakt, met de Business Owners in de zaal.
- Gedeeld eigenaarschap. Teams schrijven hun eigen objectives en zeggen die zelf toe, en dat is iets anders dan een deadline opgelegd krijgen.
Wat zijn de resultaten van PI Planning?
PI Planning levert twee resultaten op: een set toegezegde PI Objectives voor elk team en een ART Planning Board met de opleverdata van features, de afhankelijkheden tussen teams en de relevante mijlpalen.[3]
PI Objectives
PI Objectives "vatten de zakelijke en technische doelen samen die teams en trains in het komende PI willen bereiken en zijn ofwel toegezegd (committed) ofwel niet toegezegd (uncommitted)."[11] Toegezegde objectives zijn de doelen waarvan een team erop vertrouwt dat het ze kan opleveren. Niet-toegezegde objectives zijn stretchdoelen met een bekende onzekerheid. Ze worden gepland en er wordt aan gewerkt, maar ze blijven buiten de commitment, zodat één onbekende factor niet het hele plan in gevaar brengt.
Business Owners, de stakeholders met de primaire verantwoordelijkheid voor rendement op de investering, governance en compliance[12], kennen tijdens het evenement een business value toe aan elke objective. Teams gebruiken meestal een schaal van 1 tot 10. Die scores worden later vergeleken met de daadwerkelijk geleverde waarde, en zo wordt de ART Predictability Measure berekend.[3]
Goede PI Objectives zijn in gewone taal geschreven en beschrijven een resultaat dat een Business Owner herkent. "Klanten kunnen in twee nieuwe markten per automatische incasso betalen" is een objective. "Stories 4411 tot en met 4460 afronden" is een lijst.
Het ART Planning Board (program board)
Het ART Planning Board is "een visualisatie van de opleverdata van de features van het PI, de afhankelijkheden van features tussen teams en de relevante mijlpalen."[3] Het heeft één rij per team en één kolom per iteratie. Features staan in de iteratie waarin ze worden afgerond, en een lijn tussen twee kaarten betekent dat het ene team op het andere wacht.
Op een fysieke wand werd dit board gebouwd met kaartjes en rood draad. Een digitaal program board doet hetzelfde werk en blijft na het evenement actueel: wanneer een feature in Jira of Azure DevOps een iteratie opschuift, bewegen het board en de afhankelijkheidslijnen mee.
Wie nemen er deel aan PI Planning?
De volledige Agile Release Train neemt deel aan PI Planning: elk agile team, de Release Train Engineer, Product Management, de System Architect, Business Owners en andere stakeholders. SAFe gaat uit van een ART van 50 tot 125 mensen.[2]
Een Agile Release Train is "een langlopend team van Agile teams dat incrementeel een of meer oplossingen in een development value stream ontwikkelt, oplevert en vaak ook beheert."[2] Elk agile team is cross-functioneel en bestaat doorgaans uit tien mensen of minder[3], dezelfde teamgrootte die de Scrum Guide aanbeveelt.[13]
| Rol | Wat ze doen tijdens PI Planning |
|---|---|
| Release Train Engineer (RTE) | Leidt en faciliteert het evenement, presenteert het planningsproces en de verwachte resultaten en bewaakt de tijd van de agenda. SAFe omschrijft de RTE als "een dienend leider en coach van de ART."[14] |
| Business Owners | Presenteren de businesscontext, nemen deel aan de managementreview en kennen business value toe aan de PI Objectives van elk team.[12] |
| Product Management | Presenteert de productvisie en de features met de hoogste prioriteit uit de ART Backlog, meestal gerangschikt met WSJF.[15] |
| System Architect | Presenteert de architectuurvisie, enablers en niet-functionele eisen, en helpt teams technische afhankelijkheden te vinden. |
| Product Owners | Brengen de team-backlogs mee, splitsen samen met het team features op in stories en helpen bij het schrijven van de PI Objectives van het team. |
| Scrum Masters / Team Coaches | Faciliteren de team breakouts, helpen het team de capaciteit te bepalen en brengen risico's en belemmeringen in bij de Coach Sync.[3] |
| Agile teams | Schatten stories in en verdelen ze over de iteraties, identificeren afhankelijkheden en risico's, stellen concept-PI Objectives op en nemen deel aan de confidence vote. |
| Shared services en leveranciers | Sluiten aan bij de teams die van hen afhankelijk zijn, zodat hun capaciteit en data deel uitmaken van het plan en geen aanname zijn. |
Hoe vaak vindt PI Planning plaats en hoe lang duurt het?
PI Planning vindt één keer per Planning Interval plaats, dus elke 8 tot 12 weken, en is doorgaans een tweedaags evenement.[1] De meeste organisaties houden het vier of vijf keer per jaar, op data die een jaar vooruit bekend worden gemaakt.
De vaste cadans is precies waar het om gaat. Wanneer de data een jaar vooruit bekend zijn, kunnen reizen, locaties, release-mijlpalen en stuurgroepoverleggen er allemaal omheen worden gepland. Veel trains laten hun PI's samenvallen met de kalenderkwartalen, en daarom hoort u het evenement ook wel kwartaalplanning noemen.
Het evenement vindt plaats in de Innovation and Planning-iteratie. Volgens SAFe biedt de IP-iteratie "een schattingsbuffer voor het behalen van de PI Objectives en gereserveerde tijd voor innovatie, permanente educatie, PI Planning en Inspect and Adapt (I&A)-evenementen", en wordt er tijdens PI Planning geen werk in gepland.[5] Die iteratie behandelen als extra opleveringscapaciteit is een van de meest voorkomende manieren waarop trains hun voorspelbaarheid verliezen.
Hoe ziet de agenda van PI Planning eruit?
De standaardagenda van PI Planning beslaat twee dagen. Dag één omvat de businesscontext, de productvisie, de architectuurvisie, team breakouts en een review van de conceptplannen. Dag twee omvat planningsaanpassingen, de laatste team breakouts, de review van de definitieve plannen, risico's, de confidence vote en een retrospective.
De tijden hieronder vormen een voorbeeldagenda voor twee dagen die veel trains als vertrekpunt gebruiken. Pas de kloktijden aan uw werkdag aan en houd de volgorde aan.
| Tijd | Sessie | Geleid door | Doel |
|---|---|---|---|
| 08:00 tot 09:00 | Businesscontext | Business Owner of senior executive | De stand van zaken in de organisatie en wat het portfolio van deze train nodig heeft. |
| 09:00 tot 10:30 | Product- en solutionvisie | Product Management | De belangrijkste features voor het PI en de mijlpalen die ertoe doen. |
| 10:30 tot 11:30 | Architectuurvisie en ontwikkelpraktijken | System Architect | Enablers, technische richting en eventuele wijzigingen in de manier waarop teams bouwen en releasen. |
| 11:30 tot 13:00 | Planningscontext en lunch | RTE | Hoe het evenement werkt en wat "klaar" betekent voor deze twee dagen. |
| 13:00 tot 16:00 | Team breakouts 1 | Teams | Capaciteit per iteratie, stories, conceptobjectives, afhankelijkheden en risico's. |
| 16:00 tot 17:00 | Review van de conceptplannen | Teams | Elk team presenteert zijn conceptplan, objectives, risico's en afhankelijkheden. |
| 17:00 tot 18:00 | Managementreview en probleemoplossing | RTE met Business Owners | Knelpunten rond scope, mensen en afhankelijkheden uit de conceptplannen oplossen. |
| Tijd | Sessie | Geleid door | Doel |
|---|---|---|---|
| 08:00 tot 09:00 | Planningsaanpassingen | Business Owners | Wijzigingen in scope, prioriteiten of mensen waartoe de avond ervoor is besloten. |
| 09:00 tot 11:00 | Team breakouts 2 | Teams | Plannen afronden. Business Owners kennen business value toe aan de objectives. |
| 11:00 tot 13:00 | Review van de definitieve plannen en lunch | Teams | Elk team presenteert zijn definitieve plan ter acceptatie door de Business Owners. |
| 13:00 tot 14:00 | ART-risico's | RTE | Risico's die niet binnen het team konden worden opgelost, worden besproken en geROAMd. |
| 14:00 tot 14:15 | Confidence vote | RTE | Eerst de teams en daarna de hele train stemmen over hun vertrouwen in het behalen van de objectives. |
| 14:15 tot 16:00 | Plan herzien, indien nodig | Teams | Het plan herzien tot het vertrouwen acceptabel is. |
| 16:00 tot 17:00 | Planning-retrospective en vervolgstappen | RTE | Wat u behoudt en verandert voor het volgende evenement, en hoe het PI van start gaat. |
Wat is de confidence vote?
De confidence vote "meet het geloof van de teams en de ART in hun vermogen om de vastgestelde PI Objectives op te leveren."[3] Meestal gebeurt dit als fist of five: iedereen steekt één tot vijf vingers op. Een gangbare werkafspraak is dat een gemiddelde van drie of hoger betekent dat het plan is geaccepteerd, en dat iedereen die één of twee stemt wordt gevraagd zijn of haar zorg toe te lichten, waarna het plan mogelijk opnieuw wordt herzien. In Kendis kan de confidence vote per team of voor het hele PI worden uitgebracht, en wordt de uitslag bij het plan opgeslagen.
Hoe wordt er met risico's omgegaan?
Risico's die tijdens de planning naar voren komen, worden ten overstaan van de hele train geROAMd. Elk risico wordt in een van vier categorieën geplaatst: Resolved (opgelost, niet langer een zorg), Owned (iemand neemt er de verantwoordelijkheid voor), Accepted (er kan niets meer aan worden gedaan, de train accepteert het) of Mitigated (er is een plan om de impact te beperken). De waarde zit in het gesprek en in het feit dat elk risico de zaal verlaat met een naam erbij. Bekijk hoe een ROAM-risicoregister elk risico koppelt aan de features die het bedreigt.
Tip uit de praktijkBescherm de team breakouts. Ze zijn het enige onderdeel van de agenda waarin het plan daadwerkelijk wordt gemaakt. Lopen de briefings veertig minuten uit, haal die tijd dan in het volgende PI van de briefings af, niet nu van de breakouts.
Hoe organiseert u remote of gedistribueerde PI Planning?
Remote PI Planning volgt dezelfde agenda met dezelfde resultaten, meestal verspreid over drie of vier kortere dagen om rekening te houden met tijdzones en schermvermoeidheid te beperken. De fysieke wand wordt vervangen door een digitaal planning board dat de hele train tegelijk kan bewerken en dat synchroniseert met Jira of Azure DevOps.
Het standpunt van SAFe is helder. Realtime, virtueel en face-to-face plannen "is ook effectief gebleken wanneer fysieke aanwezigheid niet mogelijk is, zolang alle leden van de ART deelnemen."[1] Dat is van belang, want gedistribueerd werken is inmiddels de normale situatie. Gallup meldt dat in mei 2026 52% van de Amerikaanse werknemers met een functie die op afstand kan worden uitgevoerd hybride werkt en 26% volledig remote.[16]
De richtlijnen van SAFe voor gedistribueerde PI Planning verdelen de voorbereiding in zes aandachtsgebieden[17]:
- Planningslocaties. Houd het aantal locaties zo laag mogelijk. SAFe raadt af om de leden van één team over meerdere locaties te verdelen wanneer dat te vermijden is.[17]
- Agenda van de PI Planning. Richt het schema opnieuw in rond de overlap in werktijden. Neem briefings op, zodat ze vooraf kunnen worden bekeken.
- Faciliteiten. Elke locatie heeft een ruimte, schermen en audio nodig waarmee collega's op afstand niet alleen te zien maar ook te horen zijn.
- Werkafspraken. Maak afspraken over camera's, reactietijden, de lengte van pauzes en de manier waarop u een ander team om hulp vraagt.
- Tooling. Eén planning board, één videoplatform, één chatkanaal per team en één voor de train.
- Facilitatie. Eén facilitator per locatie of per breakout room, en een generale repetitie vóór het evenement.
Een voorbeeldagenda voor remote PI Planning in twee tijdzones
Dit voorbeeld gaat uit van een dagelijks venster van vier uur waarin de werktijden in Midden-Europa en aan de Australische oostkust overlappen. Bij een ruimere overlap kunt u het in tweeënhalve dag doen.
| Dag | Sessies | Vóór de volgende dag |
|---|---|---|
| Dag 1 | Opening, businesscontext, productvisie, architectuurvisie, planningscontext, eerste team breakout met een Coach Sync als tussentijds controlemoment. | Teams zetten de breakouts voort binnen hun eigen werktijden. |
| Dag 2 | Teamsynchronisatie, review van de conceptplannen, managementreview en probleemoplossing, planningsaanpassingen, tweede team breakout. | Teams ronden plannen en objectives af. Business Owners scoren de objectives. |
| Dag 3 | Review van de definitieve plannen, ART-risico's en ROAM, confidence vote, herzien indien nodig, retrospective en vervolgstappen. | De RTE publiceert het plan en het overzicht van de objectives. |
Beschouw remote plannen niet als een permanente vervanging van elkaar ontmoeten. Uit eigen gegevens van Atlassian over zijn gedistribueerde personeelsbestand bleek dat bewust georganiseerde fysieke bijeenkomsten leidden tot een toename van 27% in het gevoel van verbondenheid, die vier tot vijf maanden aanhield.[18] Veel trains plannen tegenwoordig remote en komen een of twee keer per jaar fysiek bijeen. Kendis-klanten zoals Nordea stapten op korte termijn over op volledig remote PI Planning, en de pagina over gedistribueerde PI Planning laat zien hoe het board dat ondersteunt.
Tip uit de praktijkStuur vóór het evenement één pagina rond: wie de contactpersoon is in elk team, welk kanaal waarvoor wordt gebruikt en wat er gebeurt als de belangrijkste tool uitvalt. Dat beantwoordt de meeste vragen die mensen anders in het eerste uur zouden stellen.
Wat zijn de meest voorkomende uitdagingen bij PI Planning?
De meest voorkomende problemen bij PI Planning zijn een onvoorbereide backlog, briefings die de breakout-tijd opslokken, afhankelijkheden die te laat worden ontdekt, plannen die de werkelijke capaciteit negeren, objectives die als takenlijst zijn geschreven en een plan dat een week na het evenement al verouderd is.
| Uitdaging | Hoe het eruitziet | Wat het oplost |
|---|---|---|
| Backlog niet gereed | Teams zien de features voor het eerst in de breakout. | Verfijn en rangschik de belangrijkste features twee tot drie weken vooraf. Deel ze vóór het evenement. |
| Briefings lopen uit | Drie uur slides, negentig minuten plannen. | Timebox de briefings en neem ze vooraf op. Begin de breakouts op tijd, altijd. |
| Late afhankelijkheden | In iteratie drie duikt een blokkerende afhankelijkheid op. | Breng afhankelijkheden tijdens de breakouts op het board in kaart en bespreek ze in elke Coach Sync. |
| Overcommitment | Elke iteratie is voor 100% of meer gevuld. | Plan op basis van de capaciteit per iteratie, inclusief verlof, en laat de IP-iteratie leeg.[5] |
| Zwakke objectives | Objectives herhalen featuretitels en zijn niet te scoren. | Beschrijf resultaten in businesstaal en scheid toegezegd van niet toegezegd.[11] |
| Handmatig overtypen | Het plan staat op een whiteboard en wordt achteraf in Jira ingevoerd. | Plan op een board dat in realtime naar de ALM-tool schrijft. |
| Het plan veroudert | Na dag twee kijkt niemand meer naar het board. | Gebruik hetzelfde board voor de tracking. Bespreek scopewijzigingen en afhankelijkheden in de ART Sync. |
Het overtypen verdient een aparte opmerking. Met algemene whiteboards bent u snel begonnen, maar het plan dat erop wordt gemaakt is een afbeelding van de backlog en niet de backlog zelf. Iemand moet na het evenement elke story, schatting en afhankelijkheid overzetten naar Jira of Azure DevOps, en vanaf dat moment groeien de twee uit elkaar. Maakt u die afweging, bekijk dan de vergelijking met whiteboardtools.
Wat hoort er op een voorbereidingschecklist voor PI Planning?
Een PI Planning-checklist omvat drie soorten gereedheid: organisatorische gereedheid (strategie, scope, teams en rollen), inhoudelijke gereedheid (businesscontext, visie, gerangschikte backlog, architectuur) en logistieke gereedheid (data, locaties, tooling en communicatiekanalen).
Begin vier tot zes weken vóór het evenement. Voor trains die deel uitmaken van een Solution Train stemmen de Pre-Plan-activiteiten de ART's op elkaar af voordat elk van hen gaat plannen.[19]
Organisatorische gereedheid
- De scope van de planning is afgesproken: welk product, welke teams plannen samen.
- De Business Owners zijn benoemd, gebrieft en beide dagen beschikbaar.
- Elk team heeft vaste teamleden, een Product Owner en een Scrum Master of Team Coach.
- De PI-data, de iteratiedata en de IP-iteratie zijn gepubliceerd.
Inhoudelijke gereedheid
- De briefing over de businesscontext is voorbereid door een executive of Business Owner.
- De productvisie en de ongeveer tien belangrijkste features zijn gerangschikt en verfijnd.
- De architectuurvisie, enablers en niet-functionele eisen liggen klaar.
- Bekende mijlpalen, vaste data en externe toezeggingen staan op een lijst.
- De teamcapaciteit per iteratie is berekend, inclusief gepland verlof.
- De resultaten van de laatste Inspect and Adapt zijn beschikbaar voor de teams.
Logistieke gereedheid
- De locatie of het videoplatform is geboekt en getest, met breakout rooms per team.
- Het planning board is ingericht: teams, iteraties en features geladen uit Jira of Azure DevOps.
- Iedereen heeft toegang tot het board en heeft het minstens één keer geopend.
- De communicatiekanalen zijn afgesproken: één voor de train, één per team, één voor de facilitators.
- De agenda met tijdzones is verstuurd, met opgenomen briefings waar die worden gebruikt.
- Er is een terugvaloptie afgesproken voor het geval een tool of verbinding uitvalt.
Hoe voert u PI Planning stap voor stap uit met Jira of Azure DevOps?
Voer PI Planning uit in drie fasen. Richt vóór het evenement het board in en laad de gerangschikte features uit Jira of Azure DevOps. Plan tijdens het evenement stories in iteraties, breng afhankelijkheden in kaart, schrijf objectives, ROAM de risico's en stem. Schakel na het evenement hetzelfde board over naar tracking.
De stappen hieronder gaan uit van Kendis, dat in twee richtingen synchroniseert met Jira Cloud, Jira Data Center en Azure DevOps. Een wijziging op het board wordt naar de ALM-tool geschreven en een wijziging in de ALM-tool verschijnt op het board, zodat niets twee keer hoeft te worden ingevoerd. De volgorde is dezelfde bij elke tool die het plan en de backlog met elkaar verbonden houdt.
Vóór de PI Planning
- Maak het PI-board aan en stel de startdatum, de einddatum en de iteratielengte van het PI in.
- Koppel uw ALM-tool. Koppel voor Jira de relevante boards. Geef voor Azure DevOps de URL van de organisatie en een access token op.
- Maak de teams aan en koppel elk team aan zijn Jira-board of Azure DevOps-team.
- Laad de features met een Jira-filter of JQL-query, of met een Azure DevOps-query. Stories die al aan die features zijn gekoppeld, komen mee.
- Rangschik de features en leg hun business value vast, zodat teams uit een geordende backlog putten.
- Nodig de train uit en vraag iedereen het board vóór het evenement te openen.
Tijdens de PI Planning
- Stel de capaciteit in voor elk team in elke iteratie, aan het begin van de eerste breakout.
- Trek features naar iteraties en splits ze op in stories met schattingen. Nieuwe stories worden aangemaakt in Jira of Azure DevOps, gekoppeld aan de feature en toegewezen aan de sprint.
- Teken afhankelijkheden tussen kaarten en geef elke afhankelijkheid een status en een eigenaar. Lees bij afhankelijkhedenbeheer hoe ze daarna worden gevolgd.
- Schrijf PI Objectives, markeer ze als toegezegd of niet toegezegd en koppel ze aan de features waarmee ze worden gerealiseerd.
- Toets de belasting aan de capaciteit voor elk team en elke iteratie, vóór de review van de conceptplannen.
- Presenteer het plan vanaf het board in de reviews van de conceptplannen en de definitieve plannen.
- ROAM de risico's in het risicoregister en koppel elk risico aan de features die het raakt.
- Houd de confidence vote voor elk team en voor het PI.
Na de PI Planning
- Schakel het board over naar tracking. Het plan dat tijdens het evenement is gemaakt, wordt de baseline.
- Volg scopewijzigingen automatisch: features die zijn toegevoegd of verwijderd en stories die sinds de baseline van iteratie zijn veranderd.
- Bespreek afhankelijkheden en objectives in elke ART Sync, en exporteer of deel het board met stakeholders.
Er zijn aparte stapsgewijze uitwerkingen voor PI Planning in Jira en PI Planning in Azure DevOps.
Houd uw volgende twee PI Planning-evenementen gratis
Kendis is een platform voor PI Planning en tracking dat boven op Jira en Azure DevOps werkt. De gratis proefperiode duurt zes maanden, lang genoeg om twee volledige PI's te plannen en te volgen met uw echte backlog, voordat iemand een budget hoeft goed te keuren.
- 6 maanden gratis, geen creditcard
- Kies EU-hosting (OVHcloud, Frankfurt) of VS-hosting (AWS)
- Planning board, afhankelijkheden, PI Objectives, ROAM-risico's, solution boards
- Tweezijdige synchronisatie met Jira Cloud, Jira Data Center en Azure DevOps
- ISO/IEC 27001-gecertificeerd, AVG-conform (GDPR), DORA Schedule beschikbaar
- Geen gebruikerslimieten en geen installatiekosten tijdens de proefperiode
Eén proefperiode per organisatie die Kendis de afgelopen twaalf maanden niet heeft gebruikt. Na de proefperiode kost Premium Cloud $14 per gebruiker per maand bij jaarlijkse facturering, of $16 bij maandelijkse facturering, en u neemt alleen licenties af voor de mensen die plannen. SSO, Kendis AI en premium support maken deel uit van de betaalde abonnementen. Bekijk de prijzen en de voorwaarden van de gratis proefperiode.
Wat gebeurt er na de PI Planning?
Na de PI Planning voert de train het plan uit in iteraties, synchroniseert in een periodieke ART Sync, toont elke iteratie geïntegreerd werk in een System Demo en sluit het PI af met een Inspect and Adapt-evenement waarin de resultaten worden afgezet tegen de toegezegde PI Objectives.
- ART Sync. Combineert de Coach Sync en de PO Sync tot één evenement voor de train.[9] De Coach Sync "helpt de afhankelijkheden van de ART te coördineren en geeft inzicht in voortgang en belemmeringen."[3] In ouder materiaal heet dit de Scrum of Scrums.
- System Demo. Het geïntegreerde werk van alle teams wordt aan stakeholders getoond. De RTE leidt de demo.[20]
- Inspect and Adapt. Vindt plaats aan het einde van elk PI en bestaat uit drie delen: "de PI System Demo, een kwantitatieve en kwalitatieve meetreview, en een retrospective met probleemoplossingsworkshop."[21] Kendis heeft een Inspect and Adapt-module die PI's naast elkaar vergelijkt.
- ART Predictability Measure. De daadwerkelijk gerealiseerde business value wordt per team vergeleken met de geplande business value. De maatstaf is "een gemiddelde van de realisatiescore van elk team in de ART voor het PI."[3]
- Flow metrics. SAFe meet flow aan de hand van distributie, velocity, tijd, load, efficiëntie en voorspelbaarheid.[22] Bekijk flow metrics in Kendis.
Welke tools hebt u nodig voor PI Planning, en waar staan de data?
U hebt een planning board nodig dat de hele train tegelijk kan bewerken en dat gesynchroniseerd blijft met de tool waarin teams hun backlog beheren. Voor Europese organisaties en gereguleerde sectoren is de plek waar dat plan wordt gehost een selectiecriterium op zich.
Beide grote ALM-tools hebben eigen planningsweergaven, en het loont om vóór het evenement hun beperkingen te kennen:
- Jira Plans. Het Program board is alleen beschikbaar in Jira Cloud Premium en Enterprise[6], en afhankelijkheidslijnen kunnen voor maximaal tien work items tegelijk worden getoond.[23]
- Azure DevOps Delivery Plans. Een plan kan tot 20 team-backlogs uit meerdere projecten tonen[24], met het volgen van afhankelijkheden op basis van predecessor- en successor-links.[25]
Geen van beide bevat PI Objectives met business value, een ROAM-risicoregister, een confidence vote of rapportage over voorspelbaarheid, en daarom voegen trains er een PI Planning-laag bovenop aan toe. Een PI-plan bevat bovendien geen onbeduidende data. Het bevat uw roadmap, releasedata, namen van personen, toezeggingen van leveranciers en bekende risico's.
PI Planning met hosting in de EU
Onder de AVG (GDPR) mogen persoonsgegevens alleen naar landen buiten de EU worden doorgegeven als aan de voorwaarden van hoofdstuk V is voldaan.[26] Voor financiële entiteiten schrijft DORA voor dat contracten met ICT-dienstverleners de locaties vermelden waar data worden verwerkt en opgeslagen.[27] Een tool die in de EU wordt gehost door een Europese aanbieder neemt de doorgiftevraag voor de gehoste data weg.
Kendis biedt die keuze bij de aanmelding, ook voor de gratis proefperiode. De Kendis European Cloud draait op OVHcloud in Frankfurt, Duitsland, waarbij projectdata in de EER worden opgeslagen en verwerkt. De Global Cloud draait op AWS in de Verenigde Staten, en Kendis kan ook in eigen beheer worden gehost. Het platform is ISO/IEC 27001-gecertificeerd en voor klanten in de financiële sector is een DORA Schedule beschikbaar. De details staan op de pagina over beveiliging en compliance.
PI Planning: veelgestelde vragen
Wat is PI Planning in SAFe?
PI Planning is een op cadans gebaseerd evenement binnen het Scaled Agile Framework (SAFe) waarin alle teams van een Agile Release Train zich richten op een gedeelde missie en visie en het volgende Planning Interval van 8 tot 12 weken plannen. Het duurt doorgaans twee dagen en wordt geleid door de Release Train Engineer.
Waar staat PI voor in PI Planning?
PI staat voor Planning Interval. Vóór SAFe 6.0 stond het voor Program Increment, en veel tools en artikelen gebruiken die naam nog steeds. Beide verwijzen naar dezelfde timebox van 8 tot 12 weken.
Hoe lang duurt een Planning Interval?
Een Planning Interval is een timebox van 8 tot 12 weken. Een veelgebruikt patroon is vier of vijf ontwikkeliteraties, gevolgd door één Innovation and Planning-iteratie.
Hoe lang duurt PI Planning?
PI Planning op locatie duurt doorgaans twee volle dagen. Remote of gedistribueerde PI Planning houdt dezelfde agenda aan, maar wordt meestal verspreid over drie of vier kortere dagen om rekening te houden met tijdzones en schermvermoeidheid te beperken.
Wie faciliteert PI Planning?
De Release Train Engineer (RTE) leidt en faciliteert PI Planning. De RTE is eigenaar van de agenda, leidt de managementreview en de probleemoplossingssessie, faciliteert de risicobespreking en de confidence vote en zorgt ervoor dat elk team vertrekt met toegezegde PI Objectives.
Wat zijn de twee belangrijkste resultaten van PI Planning?
De twee resultaten zijn toegezegde PI Objectives voor elk team, met business value toegekend door de Business Owners, en het ART Planning Board, dat de opleverdata van features, de afhankelijkheden tussen teams en de mijlpalen toont.
Wat is het verschil tussen toegezegde en niet-toegezegde PI Objectives?
Toegezegde (committed) objectives zijn de doelen waarvan een team erop vertrouwt dat het ze in het PI kan opleveren. Niet-toegezegde (uncommitted) objectives zijn geplande stretchdoelen met een bekende onzekerheid. Er wordt aan gewerkt, maar ze tellen niet mee in de commitment, en dat beschermt de voorspelbaarheid van het plan.
Wat is de confidence vote in PI Planning?
De confidence vote meet hoe sterk de teams en de train erin geloven dat ze de PI Objectives kunnen opleveren. Meestal is het een fist of five. Een gangbare regel is dat het plan bij een gemiddelde van drie of hoger wordt geaccepteerd, en dat lage stemmen worden besproken en tot herziening kunnen leiden.
Wat betekent ROAM in PI Planning?
ROAM is de manier waarop risico's aan het einde van PI Planning worden afgehandeld. Elk risico is Resolved, Owned, Accepted of Mitigated, zodat elk risico het evenement verlaat met een besluit en een eigenaar.
Wat is het ART Planning Board?
Het ART Planning Board, voorheen het program board genoemd, is een visualisatie van de opleverdata van features, de afhankelijkheden van features tussen teams en de relevante mijlpalen voor het PI. Het heeft een rij per team en een kolom per iteratie.
Kan PI Planning op afstand plaatsvinden?
Ja. Volgens SAFe is virtueel plannen effectief gebleken wanneer fysieke aanwezigheid niet mogelijk is, zolang alle leden van de ART deelnemen. Remote PI Planning vraagt om een aangepast schema, duidelijke werkafspraken en een digitaal planning board dat synchroniseert met Jira of Azure DevOps.
Is PI Planning alleen bedoeld voor SAFe?
PI Planning is door SAFe gedefinieerd, maar het gebruik om een kwartaal met alle teams samen te plannen komt ook buiten SAFe voor, onder namen als kwartaalplanning of big room planning. De agenda en de resultaten in deze gids werken voor elke groep teams met gedeelde afhankelijkheden.
Bestaat er een gratis PI Planning-tool?
Kendis is zes maanden gratis en er is geen creditcard nodig. De proefperiode omvat het planning board, afhankelijkhedenbeheer, PI Objectives, het ROAM-risicoregister, solution boards en tweezijdige synchronisatie met Jira Cloud, Jira Data Center en Azure DevOps.
Bestaat er een PI Planning-tool die in de EU wordt gehost?
Ja. Kendis biedt een European Cloud die wordt gehost op OVHcloud in Frankfurt, Duitsland, waar projectdata in de EER worden opgeslagen en verwerkt. Er zijn ook een in de VS gehoste Global Cloud op AWS en een optie voor hosting in eigen beheer beschikbaar, en de hostingregio kan ook voor de gratis proefperiode worden gekozen.
Bronnen
Elke externe bewering in deze gids verwijst naar de primaire bron hieronder. Alle links zijn gecontroleerd op 12 oktober 2026.
- Scaled Agile, Inc.. PI Planning.
- Scaled Agile, Inc.. Agile Release Train.
- Scaled Agile, Inc.. SAFe Glossary.
- Scaled Agile, Inc.. Planning Interval (PI).
- Scaled Agile, Inc.. Innovation and Planning Iteration.
- Atlassian Support. What is the Program board in my plan?.
- Scaled Agile, Inc.. SAFe 6.0 Configurations.
- Scaled Agile, Inc.. What's new in SAFe?.
- Scaled Agile, Inc.. Essential SAFe.
- Agile Alliance signatories. Principles behind the Agile Manifesto (2001).
- Scaled Agile, Inc.. PI Objectives.
- Scaled Agile, Inc.. Business Owners.
- Ken Schwaber and Jeff Sutherland. The Scrum Guide (November 2020).
- Scaled Agile, Inc.. Release Train Engineer.
- Scaled Agile, Inc.. WSJF (Extended Guidance).
- Gallup. Global Indicator: Hybrid Work (data to May 2026).
- Scaled Agile, Inc.. Distributed PI Planning (Extended Guidance).
- Atlassian. Lessons learned: 1,000 days of distributed at Atlassian.
- Scaled Agile, Inc.. Pre-Plan.
- Scaled Agile, Inc.. System Demo.
- Scaled Agile, Inc.. Inspect and Adapt.
- Scaled Agile, Inc.. Measure and Grow.
- Atlassian Support. View and manage dependencies on the Program board.
- Microsoft Learn. Use team delivery plans (Azure Boards).
- Microsoft Learn. Track dependencies in Delivery Plans.
- GDPR-info.eu. Art. 44 GDPR: General principle for transfers.
- European Union. Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA).
Hoe deze gids wordt onderhouden: de gids wordt getoetst aan de actuele artikelen van het SAFe-framework en aan de hierboven vermelde documentatie van leveranciers, en wordt bijgewerkt wanneer terminologie of richtlijnen veranderen. Voorbeeldagenda's, checklists en praktische tips zijn adviezen van Kendis en geen officieel SAFe-materiaal. SAFe en Scaled Agile Framework zijn geregistreerde handelsmerken van Scaled Agile, Inc.