Tjekliste der repraesenterer Definition of Done kriterier

Definition of Done

Scrum-artefakt

Definition of Done er en faelles forstaelse af, hvornaar arbejde er faerdigt, og sikrer gennemsigtighed og kvalitet.

Noegleelementer

  • Faelles aftale om kvalitetskrav for faerdigt arbejde
  • Gaeldende for alle Product Backlog Items i enhver sprint
  • Sikrer gennemsigtighed om hvad 'faerdigt' faktisk betyder
  • Kan udvides over tid efterhaanden som teamet modnes
  • Organisationen kan have en overordnet DoD som minimum
  • Hvis et element ikke opfylder DoD, kan det ikke praesenteres ved Sprint Review

Definition of Done (DoD) er ikke et selvstaendigt Scrum-artefakt, men et afgerende supplement til Increment. Det er en formelt aftalt liste over kvalitetskriterier, som ethvert stuekke arbejde skal opfylde, foer det kan betragtes som "faerdigt".

Hele Scrum-teamet skal have en faelles, klar forstaelse af, hvad DoD indeholder. Denne gennemsigtighed er noedvendig for at sikre, at alle arbejder mod den samme kvalitetsstandard. Uden en eksplicit DoD risikerer teamet, at forskellige medlemmer har forskellige opfattelser af, hvornaar noget er faerdigt, hvilket forer til misforstaelser og kvalitetsproblemer.

En typisk Definition of Done kan indeholde elementer som: kode er skrevet og compiles uden fejl, unit tests er skrevet og bestaar, kode er reviewet af mindst et andet teammedlem, funktionen er testet manuelt, dokumentation er opdateret, og performancekrav er opfyldt.

DoD kan gaelde paa flere niveauer. Der kan vaere en DoD for individuelle Product Backlog Items, en for et Sprint-niveau og en for en Release. Efterhaanden som teamet modnes og deres evner forbedres, boer DoD udvides og strammes for at hoejne kvaliteten yderligere.

Hvis en organisation har en overordnet Definition of Done, skal alle Scrum-teams som minimum opfylde denne. Et individuelt team kan vaelge at tilfoeje yderligere kriterier, men kan ikke slaekke paa organisationens krav.

Naar et Product Backlog Item ikke opfylder Definition of Done, kan det ikke releases eller praesenteres ved Sprint Review som faerdigt. Det returneres til Product Backlog og kan tages ind i en fremtidig sprint. Denne disciplin sikrer, at der aldrig inkluderes halvfaerdigt arbejde i et Increment, hvilket ville underminere hele formaaet med Scrum's empiriske tilgang.