I daglig tale bruger vi oftest ”done-kriterier” og ”accept-kriterier” i flæng, men er ”done” og ”accept” synonymer for de samme kriterier, eller er der i stedet for tale om to forskellige typer kriterier som komplementærer hinanden?

Et af de essentielle kriterier for at få succes med Scrum er teamets evne til at være færdige med opgaverne når sprintet afsluttes. Jeff Sutherland, der er en af de oprindelige ophavsmænd til Scrum, mener faktisk, at evnen til at blive færdig (DONE!) giver teamet den første fordobling af effektivitet [1]. Evnen til at blive færdig hænger uløseligt sammen med en aftale om, hvad ”færdig” egentligt dækker over: Før et team giver sig til at arbejde på user stories i et sprint, må det sammen med Product Owner have en klar aftale om, hvad der skal til, for at hver enkelt user story kan blive accepteret som færdig. Denne aftale er afgørende for Scrum: Uden den vil du kunne opleve fejlkommunikation og efterfølgende frustration.

Mitch Lacey, CST og nyvalgt bestyrrelsesmedlem i Scrum Alliance, taler om done-kriterier for user stories, for sprints og for releases, samt hvorledes disse differentierer sig i forhold til hinanden [2]. Dhaval Panchal, CST, taler om, at done-kriterier går hen og bliver den primære mekanisme, som teammedlemmer anvender til at rapportere fremdrift til hinanden [3]. Han taler dermed implicit også om done-kriterier for tasks.

Med konteksten for done-kriterier strækkende sig fra tasks over user stories og sprints til releases, kan der være behov for at nuancere begrebet, således at en større præcision opnås, så det ikke misforstås, hvilken kontekst der er tale om.

For nyligt havde jeg fornøjelsen af at undervise et Product Owner certificeringskursus sammen med Scrum Trainer Bob Sarni. Under kurset kom vi bl.a. ind på done- og accept-kriterier. Bob fortalte, at han skelner mellem done-kriterier og accept-kriterier. Done-kriterier ser Bob som værende en del af de af teamets aftaler, som hidrører deres faglige praksis, mens accept-kriterier ses som værende teamets aftale med Product Owner om indholdet i de konkrete user stories. Jeg kan rigtig godt lide denne skelnen mellem done- og accept-kriterier og vil i det efterfølgende give nogle eksempler på hhv. done- og accept-kriterier.

Done-kriterier
Done-kriterier er en væsentlig del af kodekset for teamets samarbejde idet de, som tidligere nævnt, bliver den primære mekanisme for teamets kommunikation om fremdriften på opgaverne. Done-kriterier knytter sig til den enkelte opgave som teamet har identificeret under detailplanlægningen og beskriver den faglige modenhed af opgaven (se nedenstående figur).

Traditionelt set har den enkelte udvikler måske anset en opgave som afsluttet, når kildeteksten er skrevet, syntaksfejl er rettet og compileret uden fejl og advarsler. Arbejder en person med denne opfattelse sammen med andre, som først anser en opgave som afsluttet når kildeteksten er skrevet, re-factored, unit tested og integreret ind i det eksisterende system, er der tydeligvis en kommunikationsbrist, som vil forstyrre billedet af teamets reelle fremdrift.

For at undgå denne situation skal man som team have lavet konkrete aftaler om, hvad DONE indbefatter. Det kan være en god ide at have en generel aftale og så samtidig give rum for, at DONE kan beskrives alternativt for den enkelte konkrete opgave.

Efterhånden som et team modnes og bliver bedre og bedre til at udføre sine opgaver, bør teamet ligeledes udfordre sig selv ved at udvide omfanget af deres done-kriterier. Har man f.eks. gennem tiden haft et done-kriterie, som generelt har heddet, at en opgave skulle være kodet for at være færdig, er det nok ved at være tiden til, at man udvider done-kriteriet til, at det også omfatter re-factored og måske unit tested. Har man haft et done-kriterie, som for nogen tid har heddet at en opgave skulle være kodet, re-factored og unit tested, er det nok ved at være tiden til, at man udvider dette med, at opgaven ligeledes skal være integreret i det øvrige system for at være færdigt. Og så videre.

Done-kriterier er altså med til at styrke teamets kommunikation om fremdriften, samtidig er det ligeledes med til at øge kvaliteten i produktet og dermed kundens tilfredshed.

Accept-kriterier
Accept-kriterier er som tidligere nævnt teamet aftalegrundlag med Product Owner om, hvad der skal til for, at hver enkelt opgave kan betegnes som værende færdiggjort. Her taler vi ikke om, hvilke tekniske discipliner der skal være afsluttet (for en Product Owner blander sig jo ikke I hvordan teamet frembringer resultaterne), men derimod hvilke attributter ved user storien der skal være opfyldt for at være afsluttet. Disse er oftest ensbetydende med test, som skal være gennemført med et positivt resultat.

Arbejder man eksempelvis med en user story, som omfatter betaling på internettet, kan et accept-kriterie være, at man skal kunne gennemføre betalingen med navngivne kreditkort (Dankort, Visa og MasterCard). Udvikler man en tuner til strenginstrumenter (som f.eks. TC Electronic’s PolyTuner) kan accept-kriteriet for en user story, som omhandler brug ved el-bas, være, at funktionaliteten skal være verificeret med såvel fire-strenget som femstrenget og båndløse instrumenter.

Formulering af accept-kriterier er essentielt for teamet i forhold til at afgøre, om en funktion er færdig eller ej. Det er derfor en god ide at bruge den fornødne tid på dette. Uanset hvor gode accept-kriterier er, kan de dog ikke overflødiggøre nødvendigheden af et dagligt samarbejde mellem team og Product Owner. Et team bør altid benytte sig af muligheden for tidlig feedback fra Product Owner og ikke nødvendigvis vente til Sprint Review for at demonstrere den udarbejde funktionalitet for denne.

[1]: Keynote ved Scrum Gathering i München, oktober 2009
[2]: http://scrumalliance.org/articles/107-how-do-we-know-when-we-are-done
[3]: http://scrumalliance.org/articles/105-what-is-definition-of-done-dod

Muligheden for at kommentere er fravalgt for dette indlæg.