Definition of Done in Jira: spreek af wat “klaar” betekent

Een engineer rondt een wijziging af en zet het Jira-issue door. Een tester ontdekt dat het nieuwe scherm werkt, maar dat een bestaande flow kapot is. Klantenondersteuning hoort via een verwarde klant van de wijziging. Iedereen gebruikte het woord klaar, maar bedoelde iets anders.

Een Definition of Done geeft het team een gedeelde voltooiingsnorm. Die maakt de verwachte kwaliteitscontroles zichtbaar voordat het werk begint, zodat de beoordeling minder afhangt van wie eraan denkt de juiste vraag te stellen.

In deze handleiding maken we een voorbeeld voor een fictief klantenportaalteam. We onderscheiden gedeelde kwaliteitscontroles van functiespecifieke acceptatiecriteria en plaatsen beide bij een Jira-issue met Definition of Done & AC van Power Pack.

Wat is een Definition of Done?

De Scrum Guide beschrijft de Definition of Done als de kwaliteitsnorm waaraan een Increment moet voldoen. Die zorgt voor een gedeeld begrip van voltooid werk. Wanneer een organisatie een norm heeft vastgesteld, is die het minimum voor haar Scrum Teams. Zie de officiële Scrum Guide.

Zie het voor ons praktische voorbeeld als een kleine reeks vragen die het team bij elke relevante wijziging stelt. Is de implementatie beoordeeld? Zijn de afgesproken controles geslaagd? Is de informatie beschikbaar die mensen nodig hebben om de wijziging te ondersteunen?

De precieze vragen hangen af van het product en de risico's. Een openbaar klantenportaal, een intern rapport en een veiligheidskritisch systeem hebben verschillende normen nodig. De checklist van een ander team zonder gesprek kopiëren kan belangrijke gaten laten vallen en tegelijk nutteloos werk toevoegen.

Een bruikbare norm beschrijft een waarneembaar resultaat. “Hoge kwaliteit” drukt een ambitie uit. “De afgesproken regressiecontroles zijn geslaagd, met resultaten gekoppeld vanuit het Jira-issue” beschrijft iets dat een beoordelaar kan inspecteren.

Scheid gedeelde kwaliteit van functiegedrag

Ons fictieve team voegt notificatievoorkeuren toe. Klanten kunnen een wekelijkse samenvattingsmail aan- of uitzetten. Belangrijke accountberichten vallen buiten die voorkeur.

De functie heeft eigen acceptatiecriteria nodig. Een opgeslagen keuze moet bijvoorbeeld nog zichtbaar zijn nadat de klant uitlogt en terugkomt. Die eis hoort bij deze functie, omdat die beschrijft wat de klant moet ervaren.

De Definition of Done omvat de bredere voltooiingsnorm. De implementatie beoordelen, bestaand gedrag controleren dat geraakt wordt en ondersteuningsinformatie bijwerken kunnen voor veel verschillende wijzigingen gelden.

Beide lijsten zijn belangrijk. Een functie kan zich gedragen zoals gevraagd terwijl essentieel kwaliteitswerk ontbreekt. Omgekeerd bewijzen beoordeelde code en geslaagde regressiecontroles niet dat de gevraagde functie correct werkt.

Begin met de gaten die je team werkelijk ziet

Breng de mensen die het product bouwen, controleren en ondersteunen samen voor een kort gesprek. Gebruik een recent voorbeeld van werk dat klaar leek maar onverwacht vervolgwerk nodig had.

Ons portaalteam benoemt drie terugkerende problemen. Reviewopmerkingen blijven soms openstaan. Bestaande accountinstellingen krijgen weinig regressiedekking. Ondersteuningsinstructies komen pas nadat de functie beschikbaar is.

Die problemen wijzen op nuttige controles. Ze geven het team ook een reden om de norm kort te houden: elke regel moet een herkenbare fout voorkomen of een noodzakelijke kwaliteitsvoorwaarde vaststellen.

Vraag hoe iemand elke voorgestelde regel zal controleren. Als niemand het bewijs kan beschrijven, verbeter dan de formulering voordat je die invoert. “Documentatie compleet” kan gaan over releasenotities, interne ontwerpnotities of een helpartikel voor klanten. Spreek af welke informatie nodig is en waar die hoort.

Spreek ook af wie de controles normaal uitvoert. Dat gesprek kan in je gebruikelijke planningsproces plaatsvinden. Een checklist alleen wijst geen beoordelaar toe en reserveert geen tijd in iemands agenda.

Maak een praktische gedeelde checklist

Dit is de eerste versie van het portaalteam. Het is een voorbeeld van een werkafspraak, geen universele norm.

• De implementatiebeoordeling is afgerond en verplichte reviewopmerkingen zijn opgelost.
• De afgesproken acceptatiecriteria van het issue zijn gecontroleerd.
• De afgesproken regressiecontroles voor geraakte accountflows zijn geslaagd.
• De afgesproken toegankelijkheidscontroles voor gewijzigde schermen zijn geslaagd.
• Ondersteuningsinformatie weerspiegelt het gewijzigde klantgedrag.
• Controleresultaten en relevante beoordelingslinks zijn vastgelegd op het Jira-issue.

Voordat het team deze checklist gebruikt, schrijft het op wat de regressie- en toegankelijkheidscontroles omvatten. Anders kunnen twee mensen dezelfde zin afvinken na verschillend werk te hebben gedaan.

Voor het portaal omvat de afgesproken regressieset inloggen, accountinstellingen openen en een bestaand profielveld bijwerken. De toegankelijkheidsbeoordeling van gewijzigde bedieningselementen omvat toetsenbordbediening, zichtbare focus en begrijpelijke labels. Dit zijn voorbeelden van de gekozen controles van dit team, geen volledige toegankelijkheidsnorm.

Ook de ondersteuningsregel heeft een praktische uitleg nodig. Als een wijziging geen effect voor klanten heeft, moet het team vooraf een passende norm voor dat soort werk vaststellen. Laat beoordelaars geen uitzonderingen improviseren alleen om een lijst groen te krijgen.

Voeg de norm toe aan een Jira-issue

Open het relevante Jira-issue en zoek de kaart Definition of Done & AC van Power Pack. Die heeft afzonderlijke tabbladen Acceptance Criteria en Definition of Done. Selecteer Definition of Done voordat je de gedeelde controles toevoegt.

Voer voor een korte lijst de titel van een controle in en selecteer Add of druk op Enter. Richt elke titel op één beoordeelbare voorwaarde. Een lange zin met drie ongerelateerde controles maakt gedeeltelijke voltooiing moeilijk weer te geven.

Je kunt ook Bulk Import selecteren en een Markdown-lijst plakken. Plak bijvoorbeeld de zes regels hierboven met een streepje en een spatie aan het begin van elke regel. Gewone Markdown-selectievakjes worden ook ondersteund.

Importeren voegt regels toe aan het geselecteerde tabblad. Controleer het tabblad voordat je bevestigt en bekijk de resulterende lijst daarna. Dezelfde inhoud opnieuw importeren kan bestaande regels opnieuw toevoegen. Gebruik het daarom bewust en niet als vernieuwingsactie.

Gebruik niet-aangevinkte regels voor werk dat nog niet is gecontroleerd. Aangevinkte Markdown-selectievakjes worden als voltooid geïmporteerd; vinkjes uit een eerder issue mogen de beoordeling van de huidige wijziging niet vervangen.

De afgesproken norm moet handmatig in elk relevant issue worden geplaatst. Bewaar een referentieversie in de normale teamdocumentatie en plak de juiste controles in nieuwe issues. Dit is een teamwerkwijze, geen automatische verbinding tussen een centrale norm en elk issue.

Doorloop een echte beoordeling

Stel dat de functie voor notificatievoorkeuren klaar is voor beoordeling. Maya controleert de klantresultaten terwijl Priya de afgesproken regressieset controleert. Leo lost de resterende opmerkingen uit de implementatiebeoordeling op en koppelt het beoordelingsverslag.

De eerste ronde laat zien dat de voorkeur goed wordt opgeslagen, maar dat de toetsenbordfocus verdwijnt na het kiezen van Save. Het team laat de toegankelijkheidscontrole openstaan, registreert het probleem in de normale Jira-discussie en verhelpt het voordat de relevante controle wordt herhaald.

Ook de ondersteuningsinformatie is nog niet af. Dat blijft zichtbaar, ook al zijn de functiespecifieke acceptatiecriteria voltooid. De afzonderlijke lijsten helpen uitleggen waarom het team nog werk heeft.

Selecteer de knop Done pas nadat een controle werkelijk is geslaagd. Selecteer die opnieuw als nieuwe informatie betekent dat de regel weer open moet staan. Leg testresultaten, beoordelingslinks en belangrijke besluiten vast via het normale Jira- of documentatieproces van het team.

Een voltooide regel registreert het oordeel van het team. Die voert de controle niet uit, verzamelt geen bewijs en legt niet vast wie heeft gecontroleerd. Als de identiteit van de beoordelaar of het tijdstip belangrijk is, leg die informatie dan expliciet vast in je gebruikelijke beoordelingsproces.

Lees de gereedheidsindicator zorgvuldig

De tool toont per tabblad het aantal voltooide regels en het totaal. De gereedheidsindicator toont alleen Ready for Release als beide lijsten minstens één regel bevatten en alle regels in beide lijsten voltooid zijn. Anders staat er In Verification.

Die regel maakt de indicator nuttig om onafgeronde regels te zien. Hij verklaart ook waarom een voltooide Definition of Done-lijst niet tot de volledig afgeronde status leidt zolang Acceptance Criteria leeg blijft.

Beschouw de tekst als een samenvatting van de checkliststatus. Die bewijst niet dat de controles voldoende waren, het bewijs overtuigend was of het product veilig kan worden uitgebracht. Een team kan een slecht geformuleerde controle net zo gemakkelijk afvinken als een bruikbare.

De checklist blokkeert ook geen Jira-overgang of het samenvoegen van een pull request. Blijf het normale oplever- en releaseproces van je team gebruiken om die besluiten te nemen.

Houd de norm bruikbaar wanneer het werk verandert

Bekijk de norm opnieuw wanneer een terugkerend defect een ontbrekende controle blootlegt, het product wezenlijk verandert of een bestaande controle geen nuttige informatie meer oplevert.

Het portaalteam kan bijvoorbeeld ontdekken dat gewijzigde voorkeuren direct werken maar na een vertraagde synchronisatie falen. Dat kan leiden tot een bredere controleregel voor functies die van vertraagde verwerking afhangen. Het team moet eerst bepalen voor welke wijzigingen die geldt en welk bewijs succes aantoont.

Werk de referentienorm bij en bespreek hoe de wijziging op lopend werk wordt toegepast. Bestaande issuelijsten nemen die aanpassing niet automatisch over. Bekijk geraakte issues en voeg waar passend de nieuwe afgesproken controles handmatig toe.

Breid de checklist niet na elke losse fout uit. Soms is een specifiek acceptatiecriterium, een duidelijkere implementatietaak of een verandering in het beoordelingsproces een betere reactie. De gedeelde norm moet iets blijven dat het team begrijpt en echt kan toepassen.

Probeer het op één huidig issue

Kies een issue dat bijna aan beoordeling toe is. Spreek een korte gedeelde kwaliteitsnorm af, zet die op het tabblad Definition of Done en voeg de specifieke klantresultaten van dat issue toe onder Acceptance Criteria.

Doorloop de controles samen en koppel het bewijs op de plek waar je team dat normaal vastlegt. Markeer regels pas na controle als voltooid en beoordeel het resterende werk via je gebruikelijke opleverproces.

Het nuttige resultaat is een duidelijker gesprek. Wanneer iemand zegt dat de wijziging aan notificatievoorkeuren klaar is, kan het team uitleggen welke resultaten werken, welke kwaliteitscontroles geslaagd zijn en waarop die conclusie berust.

• De Scrum Guide — Definition of Done