De AI MoSCoW Prioritering Coach skill voor Claude

Het probleem dat deze skill oplost heet in elk team anders, maar het patroon is hetzelfde. De sprint begint met twaalf taken die allemaal belangrijk heten. Niemand wil toegeven dat zijn item er niet bij hoort, dus alles wordt prioriteit, en als alles prioriteit is, is niets het. Halverwege de periode blijkt de tijd op, en dan vervalt niet het minst belangrijke item maar het item van degene die toevallig niet in de vergadering zat. MoSCoW vervangt dat proces door een criterium: niet hoe belangrijk voelt dit, maar wat gebeurt er als dit er deze ronde niet in zit.

Geschreven is hij voor iedereen die een scope moet bewaken: product owners en teams die releases en sprints plannen, founders die een MVP afbakenen, marketeers met een campagne-kalender, en dienstverleners die de omvang van een project moeten vastleggen voordat er een offerte uit kan. Samen met de rest van de skill-bibliotheek stellen we hem gratis beschikbaar vanuit de dienst AI en automatisatie, zonder account en zonder verkoopmail achteraf.

Een ding moet je vooraf weten: MoSCoW is een afsprakenkader, geen rekenmodel. De methode maakt keuzes bespreekbaar en legt ze vast, maar ze rangschikt niet binnen een categorie. Heb je acht Should Haves en wil je weten welke daarvan eerst gaat, dan heb je een rekenende methode naast deze skill nodig. Daarover verderop meer, inclusief de skill die dat gat invult.

De vier categorieen lijken simpel, maar elk woord is precies gekozen. Must Have betekent niet heel belangrijk maar blokkerend: zonder dit item is de oplossing binnen deze timebox niet leverbaar, niet legaal, niet veilig of zinloos. Should Have is belangrijk en pijnlijk om te missen, maar er bestaat een workaround. Could Have is de buffer van de planning: wenselijk als er ruimte is, en het eerste dat vervalt bij tegenslag. En Won't Have this time is geen prullenbak maar een afspraak: dit gebeurt deze ronde bewust niet, en dan staat er ook bij wanneer het opnieuw op tafel komt.

Die laatste categorie is de meest onderschatte. Zonder een expliciete Won't lijst sijpelen afgevallen items geruisloos terug de scope in, en dat verschijnsel heeft een naam: scope creep. Het verschil tussen een team met en zonder die afspraak laat zich het kortst tonen als diff.

De voorbeelden in dit blok komen uit het voorbeeldscenario in het skill-bestand zelf. Het zijn illustraties van de methode, geen metingen van ons of van een klant.

De kern van het bestand is een vaste werkwijze van zes stappen. Eerst doel en timebox vaststellen, want een Must Have is altijd een Must Have voor iets, binnen een afgebakende tijd. Dan doorvragen bij ontbrekende context, met maximaal drie gerichte vragen. Dan elk item door de Must-test halen: wat gebeurt er als dit er deze timebox niet in zit, en bestaat er een workaround.

Dan per item precies een categorie en een onderbouwing van een zin, zodat het team over het criterium kan discussieren in plaats van over de persoon die het item inbracht. Dan de overload-check: komt Must Have boven de 60 procent, dan stopt de indeling en gaat elk kandidaat-Must opnieuw door de test, hardop, tot de verdeling houdbaar is of expliciet benoemd wordt dat de timebox te klein is. En als laatste het definitieve overzicht plus de Won't afspraak, uitgeschreven in zinnen die je letterlijk naar stakeholders kunt sturen.

De output heeft een verplichte structuur van vijf onderdelen: de kop met doel, timebox en belangrijkste beperking; de vier categorieblokken met per item de onderbouwing; de verdeling in aantallen en percentages met de 60 procent grens erbij; een blok risico en herverdeling dat benoemt welke Could Haves bij tegenslag als eerste vervallen; en de Won't afspraak zelf. Verder zit er een uitgewerkt voorbeeldscenario in, de MVP-lancering die deze pagina als rode draad gebruikt, een lijst van acht dingen die de skill nooit doet, een bronvermelding naar Clegg en Barker en naar DSDM, en vijf stijlregels, waaronder: toon altijd de verdeling in procenten, ook als er niet om wordt gevraagd.

Wil je zelf leren hoe je zo'n instructiebestand opbouwt, dan staat de volledige uitleg in SKILL.md schrijven.

De vuistregel komt uit DSDM: laat Must Haves niet meer dan 60 procent van de inspanning van de timebox beslaan, en plan ongeveer 20 procent van de inspanning als Could Have in. Die verhouding is geen magie maar buffer-logica. Boven de 60 procent is de planning broos: elke tegenvaller raakt dan direct een item dat niet mag vervallen, en het team kan alleen nog kiezen tussen de deadline breken of de belofte breken. Met een gezonde verdeling vangt de Could-laag de klappen op, blijven de Musts en Shoulds staan, en houdt het team zijn woord ook in een slechte week.

Operationeel wordt die regel in de overload-check uit stap vijf. De verdeling wordt altijd uitgerekend, in items en waar mogelijk in geschatte inspanning, en getoond ook als je er niet om vraagt. Komt Must Have boven de grens, dan stopt de indeling en gaat elke Must Have opnieuw door de Must-test, hardop: wat gebeurt er echt als dit vervalt.

Meestal blijkt dan dat een deel van de Musts eigenlijk Shoulds zijn met een workaround die niemand hardop wilde noemen. En blijft de lijst ook na herrangschikken te vol, dan krijg je te horen wat er dan aan de hand is: niet een prioriteringsprobleem, maar een timebox die te klein is voor het doel. Ook dat is een uitkomst, en een eerlijkere dan een planning waarvan iedereen weet dat hij niet gehaald wordt.

Handig om erbij te pakken: wie na de indeling binnen een categorie wil rangschikken, bijvoorbeeld omdat er acht Should Haves zijn, kan de lijst doorgeven aan de RICE Prioritering skill, die per item een score rekent. De twee methodes vullen elkaar precies aan: MoSCoW bepaalt wat erin mag, RICE bepaalt wat eerst gaat.

Daarna is het gebruik simpel: plak je lijst, noem je doel en je timebox, en vraag om een MoSCoW-indeling. Ontbreekt het doel of de periode, dan vraagt de skill het na met maximaal drie vragen. Loop je ergens vast bij het installeren, dan staat elke stap uitgelegd in de gids Claude skills installeren.

Even eerlijk is het bestand over wanneer je hem laat liggen, en dat zijn er vier. Voor een fijnmazige ranking binnen een categorie is MoSCoW te grof: dan wil je de rekenende aanpak van RICE. Voor pure urgentie-sortering van losse taken hoort de Eisenhower matrix. Voor een go-of-no-go-beslissing op een enkel project wil je een pre-mortem of inversie, geen categorielabels. En zonder doel en timebox begint de skill er simpelweg niet aan, want MoSCoW zonder timebox maakt alles een Must.

De belangrijkste grens is menselijk, niet methodisch: keuzes worden zichtbaar en bespreekbaar gemaakt, maar geaccepteerd moeten ze door je team worden. Als de directeur na de indeling alsnog eist dat alle zeven items Must Have zijn, dan heb je geen prioriteringsprobleem maar een capaciteitsgesprek, en dat gesprek moet een mens voeren. Wat je daarvoor meekrijgt is precies wat je in dat gesprek nodig hebt: de verdeling in procenten, de risico-analyse en de vraag wat er dan van de lijst af mag.

Een heldere scope is het halve werk: daarna moeten de Must Haves ook gebouwd, geschreven of gelanceerd worden. Staat je website of vindbaarheid op die lijst, dan laat de gratis SEO scan in enkele seconden zien waar je site nu staat, zodat je weet of dat item terecht in Must Have staat. En wil je doorpraten over wat AI verder voor je bedrijf kan doen, van losse skills tot volledige automatisering, dan doen we dat gewoon in een gesprek.