De verborgen kosten van vage Jira-tickets
Een vaag Jira-ticket lijkt zelden meteen riskant. Het echte probleem verschijnt later, wanneer verschillende mensen de open plekken met verschillende aannames invullen en meerdere dagen geconcentreerd werk uiteindelijk op het verkeerde doel gericht blijken.
Waarom vage tickets blijven bestaan
Een backend engineer pakt maandagochtend een ticket op. De titel klinkt specifiek: "Gebruikersmeldingen toevoegen voor orderupdates". De beschrijving bestaat uit twee zinnen en een link naar een Slack-thread van drie weken geleden. Dat lijkt helder genoeg. Ze besteedt drie dagen aan het bouwen van een e-mailmeldingsstroom die bij elke wijziging in de orderstatus wordt geactiveerd.
Op donderdag komt de PM tijdens de PR-review binnen en zegt: "Dat bedoelde ik niet. We hadden alleen meldingen in de app nodig voor verzendgebeurtenissen, en gebruikers moesten ze kunnen uitschakelen." Niemand zat fout. Niemand was lui. Het ticket had alleen nooit de beslissingen zichtbaar gemaakt die erin verstopt zaten.
Niemand schrijft expres een vaag ticket. Zo’n ticket ontstaat in twee minuten tussen vergaderingen door, met de oprechte bedoeling om later terug te komen en details toe te voegen. Dat gebeurt vervolgens niet. De schrijver heeft de volledige context in het hoofd. Die weet welke gebeurtenissen ertoe doen, aan welke kanalen gedacht wordt en welke gebruikers ermee te maken hebben.
Niets daarvan komt op de pagina terecht, omdat het vanzelfsprekend voelt. Voor iedereen die het niet zelf heeft opgeschreven, is het dat niet.
Jira maakt dit erger juist omdat het zo makkelijk is. Er is geen verplicht veld dat vraagt wat expliciet buiten scope valt. Er is geen vangrail die een beschrijving van minder dan twintig woorden afkeurt. Je kunt drie woorden in het samenvattingsveld zetten, de beschrijving leeg laten en op Create klikken. Jira sputtert niet tegen. Dat is tegelijk een kracht en een valkuil. Het resultaat is een backlog vol tickets die er op het eerste gezicht compleet uitzien en hun vaagheid pas tonen zodra iemand echt begint te bouwen.
Wat een echt bouwklaar plan bevat
De meeste tickets beantwoorden één vraag: wat willen we? Een bouwklaar plan beantwoordt er zes.
| Onderdeel | Welke vraag het beantwoordt |
|---|---|
| Scope | Wat erin zit, en wat er expliciet buiten valt |
| Beperkingen | Wat niet mag veranderen of kapotgaan |
| Stappen | Wat er moet gebeuren, en in welke volgorde |
| Randgevallen | Wat er gebeurt als het vanzelfsprekende pad faalt |
| Afhankelijkheden | Wat eerst aanwezig moet zijn |
| Definitie van klaar | Hoe iedereen weet dat het werk echt af is |
Dit is geen checklist voor elke minieme bugfix in de backlog. Maar alles wat een sprint in gaat, alles wat waarschijnlijk meer dan een paar uur van iemands tijd kost, heeft deze antwoorden nodig voordat het werk begint. Scope is het onderdeel dat teams het vaakst overslaan. Benoemen wat erbuiten valt voelt overbodig wanneer iedereen enthousiast is over wat er juist binnen valt. Toch begint opvallend veel herstelwerk precies daar.
Beperkingen zijn de stille vereisten:
- Breek de bestaande ordermailstroom niet.
- Blijf binnen de huidige notificatieservice.
- Geen nieuwe infrastructuur in deze sprint.
Deze details worden zelden opgeschreven omdat de auteur ervan uitgaat dat iedereen ze al kent. Dat is niet zo. En de definitie van klaar is de grens tussen "ik denk dat dit af is" en "we zijn het erover eens dat dit af is". Een goede definitie van klaar is zichtbaar en toetsbaar.
Vragen komen vóór structuur
Elke Jira-omgeving gaat uiteindelijk door dezelfde cyclus. Iemand voegt een beschrijvingssjabloon toe met onderdelen als Samenvatting, Acceptatiecriteria, Technische notities en Buiten scope. Een paar weken lang vullen mensen dat in. Daarna verspreidt dezelfde vage taal die eerst in een kale beschrijving zat zich gewoon over meer gelabelde vakken. De structuur is verbeterd. Het denken niet.
Sjablonen lossen het probleem niet op, omdat het probleem niet structureel is. Het is cognitief. De schrijver weet niet wat er ontbreekt. Een leeg onderdeel met de titel Randgevallen helpt iemand niet die nog helemaal niet over randgevallen heeft nagedacht. Vragen doen dat wel. Specifieke, concrete vragen die beslissingen afdwingen.
Vijf vragen halen verborgen beslissingen bijzonder goed naar boven:
- Wat verandert er in het gedrag van het systeem?
- Wie is de belangrijkste gebruiker, en wat probeert die te bereiken?
- Is er een situatie waarin dit juist niet moet gebeuren?
- Wat breekt er als we dit niet opleveren?
- Geldt dit voor bestaande gebruikers, nieuwe gebruikers of voor beide?
Deze vragen werken omdat ze concreet genoeg zijn om te beantwoorden, maar breed genoeg om op bijna elk featureticket toepasbaar te zijn. Het beantwoorden ervan ís al planning. Het sjabloon is alleen de plek waar de antwoorden terechtkomen.
Volledig voorbeeld
Zo ziet dit er in de praktijk uit. Het oorspronkelijke ticket is klein: "Gebruikersmeldingen toevoegen voor orderupdates". In de beschrijving staat alleen dat gebruikers een melding moeten krijgen wanneer de orderstatus verandert, plus een notitie om met design af te stemmen hoe het eruit moet zien. Dat is genoeg om het een sprint in te trekken, maar lang niet genoeg om met vertrouwen te bouwen.
Een korte verduidelijkingsronde verandert alles:
| Verduidelijkende vraag | Antwoord |
|---|---|
| Welke statuswijzigingen zijn relevant? | Alleen verzonden en geleverd |
| Welke kanalen? | Alleen in de app voor deze sprint |
| Kunnen gebruikers zich afmelden? | Ja, met standaard ingeschakeld |
| Wat met gebruikers die offline zijn? | Zet de melding klaar voor de volgende login |
| Geldt dit voor bestaande orders? | Nee, alleen voor nieuwe |
| Wat gebeurt er als levering mislukt? | Eén keer opnieuw proberen, daarna loggen |
Vijftien minuten later betekent het ticket voor iedereen hetzelfde. De versie daarna heeft echte scope, echte beperkingen, geordende stappen, echte randgevallen en een definitie van klaar die toetsbaar is. Het is hetzelfde ticket. De helderheid is totaal anders. Het verschil zit niet in een beter sjabloon. Het zit in een kleine hoeveelheid doelgerichte vragen vóór het werk begint.
Waar AI in dit proces past
AI schrijft geen tickets. Mensen schrijven tickets. Maar AI is wel nuttig op een heel specifiek moment in het proces: nadat de bedoeling er is, voordat de structuur definitief vastligt. Een taalmodel kan een vage beschrijving lezen en vragen: "Hebben jullie meegenomen wat er gebeurt als de gebruiker offline is?" Het kan losse antwoorden uit een Slack-thread ordenen in scope, beperkingen en stappen. Het kan opmerken dat het plan een databasemigratie noemt, terwijl in de afhankelijkheden niet staat dat de juiste mensen dat moeten beoordelen.
Waar AI niet goed in is, is productbeslissingen voor jullie nemen. Het kan vragen of dit e-mail, push of in-app moet zijn. Het kan niet bepalen welke van die opties juist is voor jullie gebruikers en deze sprint. Het kan een aannemelijke definitie van klaar genereren, maar alleen iemand die het product echt begrijpt kan zeggen of die definitie klopt.
Het patroon is eenvoudig: mensen beslissen, AI ordent. Mensen zetten de scope, AI ziet de gaten. Dat is precies het patroon, verduidelijken, plannen, uitvoeren, waarop Just op de Atlassian Marketplace in Jira is gebouwd. Datzelfde patroon werkt ook handmatig. AI maakt de cyclus alleen sneller.
Drie dingen die je vandaag kunt toepassen
- Kies vóór je volgende sprint het vaagste ticket uit je backlog en stel de vijf vragen uit dit artikel voordat iemand code schrijft. Je zult vrijwel zeker minstens twee beslissingen vinden waarvan niemand doorhad dat ze nog niet genomen waren.
- Schrijf de antwoorden op als scope, beperkingen en een toetsbare definitie van klaar, niet in een apart document maar in het ticket zelf, precies daar waar de bouwer ze ook echt zal zien.
- Zie het sjabloon hierboven als vertrekpunt, niet als strakke norm. Pas het aan aan de taal van je team, maar sla de vragen niet over. Als je het bredere kader wilt begrijpen waarom deze verduidelijkingsstap nog belangrijker wordt zodra vage tickets rechtstreeks aan AI worden doorgegeven, dan legt het eerste artikel in deze reeks het alignment-probleem uitgebreider uit: Waarom de meeste AI-tools voor Jira het alignment-probleem erger maken in plaats van oplossen.
