Geen theorie. Dit zijn de patronen die ik het vaakst mis zie gaan, inclusief praktische fixes en voorbeelden uit de praktijk.
PI Planning kan een van de sterkste interventies zijn die je als organisatie kunt doen. Niet omdat het een event is, maar omdat het een moment is waarop je collectief drie dingen doet:
En toch zie ik het keer op keer misgaan. Niet door onwil, maar door patronen die zich razendsnel herhalen zodra de druk oploopt.
Dit artikel is een praktische lijst. Geen theorie. Dit zijn de anti‑patronen die je PI onschadelijk maken, plus de fixes die ik in de praktijk het vaakst heb zien werken.
---
Een goede PI levert niet vooral veel post-its op. Een goede PI levert:
Als je PI dit niet oplevert, dan is het hooguit een dure workshop.
---
Symptoom: er staan 25 epics op de agenda, iedereen heeft een mening, niemand durft iets te schrappen.
Waarom het gebeurt: niemand wil de bad guy zijn, en besluiten worden uitgesteld tot “het team het oplost”.
Fix:
Voorbeeld uit de praktijk:
In een ART met 9 teams wilden drie afdelingen allemaal “hun” epics in de PI. Het werd een onderhandelsessie zonder einde. De doorbraak kwam pas toen de business owner hardop zei: “Als we maar twee dingen doen: dit en dit. De rest schuift.” De sfeer werd even ongemakkelijk. En daarna werd het eindelijk een plan.
Paradox die je moet managen: hoe meer je “alles open laat”, hoe minder keuzevrijheid je overhoudt tijdens de PI.
---
Symptoom: objectives zijn mooie zinnen, maar niemand kan achteraf zeggen of het gehaald is.
Waarom het gebeurt: objectives worden gebruikt om iedereen blij te houden, niet om te sturen.
Fix:
Voorbeeld uit de praktijk:
Een team had als objective: “Verbeter onboarding.” Aan het einde van de PI was er wel gewerkt, maar niemand wist of het beter was. De volgende PI maakten we er van: “Onboarding doorlooptijd van 14 → 7 dagen, gemeten op 10 nieuwe klanten.” Toen veranderde het gesprek ineens: wat is écht nodig, en wat is nice-to-have?
---
Symptoom: teams plannen 100% vol en raken in week 2 al achter.
Waarom het gebeurt: “druk” wordt gezien als “productief”, en onplanned work wordt structureel onderschat.
Fix:
Voorbeeld uit de praktijk:
Een team committeerde op 40 story points per iteratie, terwijl er elke week 1–2 dagen productiesupport was. Iedere iteratie “liepen ze achter”. Toen we support expliciet als capacity drain boekten, zakte de geplande scope. De output steeg, omdat ze ineens afmaakten in plaats van starten.
Paradox: 100% bezetting voelt efficiënt, maar levert de minste output op.
---
Symptoom: dag 2 verandert in dependency bingo. Teams wachten op elkaar en re‑plannen de hele dag.
Waarom het gebeurt: afhankelijkheden worden pas zichtbaar als teams al aan het plannen zijn. Dan is het te laat.
Fix:
Voorbeeld uit de praktijk:
Bij een PI bleek ineens dat Team A een API wijziging van Team B nodig had, maar Team B had die helemaal niet ingepland. Resultaat: twee iteraties vertraging, veel frustratie. De volgende PI deden we 1 week vooraf dependency mapping. Het plan werd kleiner, maar wél haalbaar.
---
Symptoom: “het is bijna af” in week 10, en dan blijkt security/QA/documentatie nog te ontbreken.
Waarom het gebeurt: teams plannen op ‘dev done’, terwijl de organisatie waarde pas ziet bij ‘release done’.
Fix:
Voorbeeld uit de praktijk:
Een feature was “af” op vrijdagmiddag. Maandag bleek de monitoring niet ingericht, en security moest nog reviewen. Release schoof 3 weken. Sindsdien stond er in DoD: “observability + security sign-off”, en konden we eindelijk echt voorspellen.
---
Symptoom: je optimaliseert het event (strakke agenda), maar niet de flow in de PI.
Waarom het gebeurt: PI wordt behandeld als projectplanning, niet als operating model.
Fix:
Voorbeeld uit de praktijk:
Een ART had een fantastische PI agenda, maar na week 1 sprak niemand elkaar meer. Geen demo’s, geen integratiemomenten. Gevolg: alles kwam samen in de laatste iteratie. Toen we demo- en integratieritme vastzetten, ging ‘last minute integratie’ omlaag en kwam rust terug.
---
Symptoom: iedereen is vriendelijk, maar niemand benoemt dat het plan niet klopt.
Waarom het gebeurt: conflict vermijden. Of: de RTE is bang “de energie te breken”.
Fix:
Voorbeeld uit de praktijk:
Tijdens commitment was iedereen blij, maar één team had overduidelijk te veel werk. De RTE stelde één vraag: “Wat laten jullie vallen als de eerste integratie tegenvalt?” Stilte. Toen werd het plan aangepast. Pijnlijk in het moment. Redelijker in de realiteit.
---
Symptoom: na de PI is niemand het eens over wat er is afgesproken.
Waarom het gebeurt: iedereen is moe na PI, en er is geen eigenaar van de waarheid.
Fix:
Voorbeeld uit de praktijk:
Een maand na PI vroeg een stakeholder: “Wat was ook alweer de afspraak over X?” Drie verschillende antwoorden. Sindsdien hadden we één PI‑pagina per ART. Niet perfect, wel één waarheid.
---
Symptoom: ROAM wordt gedaan omdat het moet, niet omdat het helpt.
Waarom het gebeurt: risico’s krijgen geen owner, geen actie, geen ritme.
Fix:
Voorbeeld uit de praktijk:
“Vendor levert mogelijk laat” stond als risico op de muur. Niemand deed iets. Toen het misging, was het crisis. De volgende PI hadden alle top risico’s een actie binnen 48 uur na PI. Resultaat: minder verrassingen, minder escalaties.
---
Symptoom: PI wordt iets dat “het event” oplost. Scrum Masters faciliteren, maar challengen niet. Product Owners schrijven wel stories, maar maken geen keuzes. Product/Project Managers (of Epic Owners) brengen input, maar geen trade-offs.
Waarom het gebeurt: onduidelijke rolverwachtingen, te veel druk, of iedereen wacht op elkaar.
Fix:
- SM/RTE: transparantie, flow en escalatie. Niet alleen facilitation.
- PO/PM: prioriteiten en trade‑offs. Niet alleen ‘input ophalen’.
- Architect/Tech leads: afhankelijkheden en haalbaarheid hard maken.
Voorbeeld uit de praktijk:
Een PO nam alles aan “want de business wil het”. Een SM wilde de sfeer goed houden. Resultaat: een plan dat in week 3 brak. Toen we PO’s mandaat gaven om nee te zeggen en SM’s expliciet de rol gaven om scope te challengen, werd PI kleiner, maar de predictability ging eindelijk omhoog.
---
Symptoom: objectives blijven vaag, prioriteiten schuiven per gesprek, escalaties blijven hangen. Na PI komt alsnog: “maar dit moet er ook nog bij”.
Waarom het gebeurt: drukte, onduidelijke rol, of BO’s hebben geen mandaat om echt te kiezen.
Fix:
- opening (outcomes + prioriteiten)
- scope trade-offs / escalaties
- commitment moment
Voorbeeld uit de praktijk:
In een PI waren de business owners alleen bij de kick-off. Dag 2 liepen teams vast op trade-offs. Niemand durfde te kiezen. De PI eindigde met een ‘optimistisch’ plan. Twee weken later veranderde de business de topprioriteit en stortte het plan in. De volgende PI stond er een BO‑blok na dependency review. Daar werden beslissingen genomen. PI werd ineens een stuurinstrument.
---
Symptoom: besluiten blijven hangen, scope trade-offs worden “uitgesteld”, escalaties stapelen op.
Waarom het gebeurt: executives willen wel sturen, maar niet in de kamer zijn als het schuurt.
Fix:
- opening (outcomes + prioriteiten)
- commitment moment
- escalaties / scope trade-offs
Voorbeeld uit de praktijk:
Een ART had een scope conflict tussen compliance en delivery. Zonder exec bleef het een discussie. Toen de exec 20 minuten inbelde en één trade-off maakte, kon iedereen verder. Soms is het letterlijk dat simpel.
---
Symptoom: iedereen gaat weer rennen, en het plan verdampt.
Waarom het gebeurt: PI is “klaar”, dus de organisatie gaat terug naar oude reflexen: nieuw werk erin, geen herplanning, geen eerlijk gesprek.
Fix:
- wanneer meten we predictability?
- welke signalen triggeren herplanning?
- hoe behandelen we nieuw werk?
Voorbeeld uit de praktijk:
Na PI kwam er in week 1 meteen “urgent werk” binnen. Zonder afspraken schoof het plan op en werd het een sluipende scope creep. Met een follow-up contract ("nieuw werk = trade-off met BO") bleef het eerlijk: óf we schuiven, óf we stoppen iets anders.
---
Als je maar drie dingen doet vóór je volgende PI:
---
Als je wilt, kijken we samen naar jullie huidige PI setup (format, ritme, outputs) en maken we in één gesprek een concreet verbeterplan.
Plan een intake: https://northstarpartners.nl/contact.html
Of bekijk PI begeleiding (PI Dokter): https://northstarpartners.nl/pi-dokter.html
Wij helpen organisaties met PI planning begeleiding: format, ritme, outputs, en het moeilijke stuk. Keuzes, trade-offs en opvolging.