Antwoord.

Historisch gezien was het formuleren van acceptatiecriteria (acceptance criteria) de verantwoordelijkheid van testers of het ontwikkelingsteam. Echter, met de overstap naar flexibele schaalbare processen (SAFe, LeSS, Scrum-of-Scrums) ontstaan er risico's van discrepantie in verwachtingen tussen verschillende deelnemers aan een groot project: business, testen, ontwikkelaars en support kunnen taken op verschillende manieren interpreteren.

Het probleem in multi-team of gedistribueerde projecten is: verschillende verantwoordelijkheidsgebieden, verschillende processen en tools, en taal- of culturele verschillen tussen teams. Zelfs gedetailleerd uitgewerkte vereisten kunnen leiden tot conflicterende of onvolledige acceptatiecriteria, wat resulteert in bugs en ontevredenheid bij de business.

De oplossing is de betrokkenheid van de systeemanalist in een vroeg stadium van het formuleren van acceptatiecriteria, het afstemmen van vereisten tussen teams, strikte formaliseringsprocessen en gezamenlijke discussie van scenario's en edge-cases tijdens een gezamenlijke demo of groepsworkshop.

Belangrijke kenmerken:

Acceptatiecriteria moeten eenduidig, meetbaar, reproduceerbaar en valideerbaar zijn.
Voorafgaande afstemming van criteria (handmatige checklist + voorbeelden van verwachte gegevens/gedrag).
Wederzijdse tracing: criteria moeten altijd verwijzen naar vereisten, cases en user stories, zodat elke doelstelling te traceren is.

Vragen met een bezwaar.

Kan het formuleren van acceptatiecriteria volledig aan testers worden overgelaten?

Nee, de analist moet deelnemen. Alleen hij heeft de volledige kennis van de businesscontext en kent alle nuances van de vereisten.

Moeten acceptatiecriteria alleen positieve scenario's dekken?

Nee, het is noodzakelijk om negatieve en grensgevallen (edge cases) toe te voegen, anders ontstaan er hiaten in de implementatie en het testen.

Kunnen acceptatiecriteria mondeling worden vastgesteld in multi-teamprojecten?

Nee, mondelinge afspraken kunnen de druk van gedistribueerde interactie niet weerstaan en leiden tot conflicten. Criteria worden alleen formeel aanvaard (bijvoorbeeld in de vorm van Gherkin/BDD of gestructureerde checklists).

Typische fouten en anti-patronen

Formulering van acceptatiecriteria "per definitie", zonder verwijzingen naar vereisten en specificaties.
Gebrek aan feedback van eindteams.
Het negeren van interactiescenario's tussen componenten van verschillende teams, vooral bij integraties.

Voorbeeld uit het leven

Negatief geval: In een bankapplicatie werden de acceptatiecriteria voor de functionaliteit van overschrijvingen alleen met één team afgestemd. Het tweede team implementeerde zijn interne interfaces zonder rekening te houden met de eerste blok criteria, wat leidde tot afwijkingen in de formaten van transactie-ID's.

Voordelen:

Snelle start van de implementatie.

Nadelen:

Noodzaak tot refactoring van de API.
Tijdverlies bij het oplossen van conflicten.

Positief geval: De analist organiseerde een serie workshops met visuele scenario's en details voor alle betrokken teams, met verplichte schriftelijke vastlegging van de acceptatiecriteria in Confluence/JIRA met tweezijdige tracing naar de vereisten.