Definition of Done: Eksempel, sjekkliste og workshop i Scrum

Her om dagen forberedte jeg en workshop sammen med en kollega. Vi ble raskt enige om innholdet, det eneste som manglet var en passende PowerPoint-presentasjon. For å kunne jobbe med presentasjonen så effektivt som mulig, delte vi den opp tematisk. Da vi satte oss ned for å diskutere det ferdige utkastet, ble et stort problem tydelig: Vi hadde svært ulike oppfatninger av hva som faktisk kjennetegner et “ferdig utkast”. 

Dette problemet kan også oppstå i agile Scrum-team. Etter to uker når teamet slutten av sprinten, men det er uenighet om hvorvidt produktinkrementet allerede er ferdig og kan flyttes fra “in progress” til “done”. Denne uenigheten fører til diskusjoner som igjen påvirker klimaet i teamet negativt. For å forhindre slike diskusjoner og sikre et effektivt teamarbeid finnes det en artefakt i Scrum-verdenen som kalles “Definition of Done” (DoD). 

Hva er Definition of Done i Scrum?

Definition of Done er Scrum-teamets felles kvalitetsavtale. Den beskriver hvilke betingelser som må være oppfylt for at et inkrement skal regnes som ferdig og brukbart. Det er ikke en personlig oppgaveliste og heller ikke en ekstra godkjenning fra én enkelt rolle, men en transparent standard for hele teamet.

Definisjon av ferdig betyr bokstavelig talt “definisjon av ferdig”. Det betyr at teamet blir enige om hva som må gjøres for at en funksjon skal anses som ferdig. I praksis kan Definition of Done fremstilles som en slags sjekkliste som brukes i løpet av sprinten og spesielt på slutten for å sjekke om visse ferdigstillelseskriterier er oppfylt. For programvareutviklingsteam kan disse kriteriene for eksempel være følgende: 

Definition of Done eksempel: Sjekkliste for Scrum-team

En praktisk Definition of Done kan for et programvareprodukt for eksempel inneholde følgende kriterier:

• Akseptansekriteriene og de faglige kravene er oppfylt.
• Dokumentasjon er utarbeidet.
• Koden er fullstendig implementert og kommentert.
• Det ble gjennomført en kodegjennomgang.
• Automatiserte tester kjører vellykket; relevante feil og sikkerhetsrisikoer er håndtert.
• Endringen er integrert og kan verifiseres i et produksjonsnært miljø.
• Overvåking, logging og eventuelt releasenotater er tatt hensyn til.
• Inkrementet er brukbart og oppfyller produktets kvalitetsstandard.
• …

Denne listen er et eksempel, ikke en universell mal. En god DoD beskytter kvalitet, er anvendelig for teamet i hvert sprint og justeres når produkt, risikoer eller tekniske rammebetingelser endrer seg.

Definition of Done er ikke det samme som produktvirkning

En Definition of Done besvarer et viktig spørsmål: Oppfyller inkrementet den avtalte kvalitetsstandarden, og er det brukbart? Den besvarer imidlertid ikke automatisk om endringen oppnår ønsket effekt i markedet eller hos kunden.

For praksis hjelper det derfor å skille mellom tre nivåer:

• Done: Inkrementet oppfyller Definition of Done og kan brukes.
• Done-Done: Endringen er integrert, levert og kan observeres i drift.
• Produktvirkning: Reell kundetilbakemelding viser om endringen løser et relevant problem og øker produktverdien.

John Cutler beskriver derfor programvare som et kontinuerlig videreutviklet servicesystem: Funksjoner er ikke endelige byggverk, men midlertidige midler for å skape kundeverdi. Les perspektivet hans i The Work Is Never Done.

Gil Zilberfeld skiller dessuten mellom ulike betydninger av «Done» – for eksempel når utvikling, tester, levering eller kundetilbakemelding hver markerer en annen grad av ferdigstillelse. Hans inndeling finner du i The Definition of Done, Done-Done and Really Done.

Viktig: «Produktvirkning» bør ikke bare formuleres som et अतिरिक्त DoD-kriterium. Et Scrum-team må levere et brukbart inkrement; om det oppnår ønsket effekt, blir deretter synlig gjennom Sprint Review, bruk og videre læringssløyfer. Nettopp dette skillet beskytter Definition of Done mot å bli en uoppnåelig samleliste.

Hvordan Definition of Done samspiller med andre virksomme Scrum-praksiser, viser vi i vår artikkel Scrum Best Practices 2026.

Hvorfor er en definisjon av “ferdig” viktig?

At målsetting har stor betydning for prestasjoner, er ingen ny innsikt. Målsetting er et mye utforsket tema innen psykologien (jf. Locke & Latham, 2006). Det har vist seg at prestasjonene er høyest når målene er så spesifikke og utfordrende som mulig uten å virke uoppnåelige. Definition of Done er imidlertid ikke en metode for å sette mål (men hvis den skal brukes, er det en metode for å sette mål). Støtte til å sette seg mål Hvis du trenger hjelp, hjelper vi deg gjerne); det er snarere snakk om kriterier som må oppfylles for å nå målet. 

Disse kriteriene er viktige for å skape en felles forståelse i teamet. En forståelse av hva hvert enkelt teammedlem må oppnå for å nå det felles målet. Det handler altså om individuelle prestasjoner som til syvende og sist utgjør en teamprestasjon.

Hvis vi ser på spørsmålet om DoD fra produkteierens ståsted, blir helt andre problemer tydelige. Hvis det ikke er klart definert når et produktinkrement anses som ferdig, kan det føre til uenighet med kunden når produktet presenteres for ham. Hvis dette skjer og et uferdig produkt presenteres, blokkeres muligheten for tilbakemelding fra kunden. 

Kontinuerlig forbedring

Siden en Definition of Done ikke er et statisk konsept, men kan og bør være i konstant utvikling eller endring, gir den også teamet mulighet til å lære. Hvis teamet på slutten av en sprint innser at det ikke klarte å oppfylle kriteriene i definisjonen av ferdig, kan teammedlemmene enten justere definisjonen av ferdig for å tilpasse den til de faktiske resultatene, eller så kan teamet trekke konklusjoner for neste sprint og endre sin egen arbeidsmåte.

Prøv Echometer gratis nå og få ny inspirasjon til retrospektivene dine!

Test Echometer gratis

Disse refleksjonene over definisjonen av ferdig bør gjøres av teamet under retrospektivet. Mulig Echometer-artiklerSpørsmålene som kan stilles som forberedelse er 

Vi har klare Definitions of Done for våre krav.

Jeg vet som regel hvor vi står når det gjelder å nå våre felles mål.

Mål: Målene mine er i tråd med målene til kollegene mine.

Teamet dekker all den kompetansen vi trenger for å nå målet vårt.

De setter ikke bare spørsmålstegn ved om det i det hele tatt finnes en “Definition of Done” i teamet, men også hvordan åpenhet, autonomi og rolleklarhet er i teamet.

Du finner hele vareutvalget i vår Retro-verktøy.

Hvordan kan teamet vårt definere det som er gjort? Et eksempel på en workshop

Vi har vist deg hva en Definition of Done er og hvorfor den er viktig for effektivt samarbeid i Scrum-team. Men hvis teamet ditt ikke har opprettet en DoD ennå, lurer du sikkert på hvordan den fungerer. 

I prinsippet er det viktig at teamet tar seg god tid til å utarbeide dokumentet. Til slutt bør man ende opp med et dokument som alle teammedlemmene kan identifisere seg med, og som ikke bare blir sett på som et nødvendig onde. Derfor anbefaler vi et workshop-lignende format med Scrum Master som ordstyrer. Hvert teammedlem bør tenke gjennom hvilke kriterier som er viktige for ferdigstillelsen av produktet, og teamet kan deretter oppsummere disse tankene. På samme måte har vi utviklet et workshopformat for målsetting. Ta en tittfor å få ideer til din Definisjon av ferdig-workshop! 

Den ferdigstilte DoD-en kan brukes i retrospektiver, for eksempel i form av trafikklyset Definition-of-Done:  

1. Skriv kriteriene for definisjonen av ferdig under hverandre.
2. Tegn en rød, en gul og en grønn firkant ved siden av hver av dem.
3. For hvert element i Definition of Done markerer teammedlemmene om det ble implementert godt, middels godt eller dårlig i forrige sprint. 
4. Diskuter de tre som nevnes hyppigst i det røde området.
5. Juster definisjonen av ferdig om nødvendig.

Konklusjon – Ferdig?

Noen ord til slutt: Det finnes ikke noe som heter “ferdig” i det agile miljøet. Ferdig betyr bare at noe er foreløpig ferdig, men at det når som helst kan og bør gjøres ytterligere justeringer og forbedringer. Dette er et av de mange vakre aspektene ved smidig arbeid: kontinuerlig forbedring. 

Spesielt spennende: Noen ganger er punkter “ferdige” helt til kunden kommer og stiller spørsmål ved hele løsningen, og dermed rokker ved grunnlaget for antakelsene om kundens behov. I slike situasjoner blir det tydelig om teamet virkelig har prioritert kundefordeler fremfor fremdrift i sakssystemet.

En klar definisjon av hva som er gjort, kan bidra til å unngå konflikter og øke ytelsen. Hvis du er interessert i flere måter å nå dette målet på, bør du også ta en titt på artikkelen vår om den fantastiske sannheten bak det smidige tankesettet se. Eller berik tilbakeblikkene dine ved å ta hensyn til de nyeste vitenskapelige funnene innen psykologi.

Nettopp for å oppfylle dette løftet har vi utviklet retroverktøyet Echometer. Hvis du er interessert i hvordan (og om) Echometer fungerer, kan du lese Holgers erfaringsrapport om verktøyet vårt:

Vil du ta teamet ditt til et nytt prestasjonsnivå? Retro-verktøyet vårt kan hjelpe deg med det. Her er Holgers erfaringer med det:

Holgers erfaringsrapport om Remote Retro-verktøyet

Vanlige spørsmål om Definition of Done

Hva hører inn i en Definition of Done?

I en Definition of Done hører alle kvalitetskriteriene inn som et inkrement må oppfylle for å være brukbart. Typiske eksempler er oppfylte akseptansekriterier, kodegjennomgang, tester, sikkerhetskontroll, dokumentasjon og den tekniske muligheten for levering. Hvilke punkter som gjelder, bestemmer teamet ut fra sin produktkontekst.

Hvem lager Definition of Done i Scrum?

Scrum-teamet utvikler og vedlikeholder Definition of Done sammen. Den bør ikke fastsettes av én enkelt rolle som en kontrolliste. Organisasjoner kan sette minimumsstandarder, men teamet må forstå dem og kunne bruke dem i det daglige.

Hva er forskjellen mellom Definition of Done og Definition of Ready?

Definisjonen av Done beskriver når et inkrement er ferdig og brukbart. En Definition of Ready kan derimot inneholde kriterier for forberedelsen av et arbeidselement, men er ikke et offisielt Scrum-artefakt og må ikke brukes til å skyve ansvar eller tilbakemeldingssløyfer over på andre.

Praktisk eksempel: Vår interne Definition of Done hos Echometer

En Definition of Done må ikke stoppe ved kode og tester. Echometer bruker internt en mer omfattende standard som, i tillegg til funksjonalitet, også tar hensyn til UX, vedlikeholdbarhet, observerbarhet og forberedelsen av releasen. Det følgende eksempelet viser hvordan et team kan gjøre sine egne kvalitetskriterier konkrete og verifiserbare:

Område	Eksempelvise kriterier
Funksjonalitet	Den spesifiserte funksjonen fungerer, typiske edge cases er testet, det finnes ingen kjente feil, uferdige funksjoner er beskyttet med feature flag, og relevante bruksdata blir registrert.
UX	Tomme tilstander, lastetilstander, tilgangsrettigheter, feilhåndtering, lokalisering og responsiv visning er tatt hensyn til.
Vedlikeholdbarhet	Coding Guidelines og relevante konvensjoner er fulgt, unødvendig kode og bevisst etterlatt teknisk gjeld er unngått, og viktig informasjon for monitorering og feilsøking er tilgjengelig.
Utrulling	Endringen er rullet ut i produksjon eller bevisst klargjort med feature flag, release notes er oppdatert, og berørte interessenter blir informert ved behov.

Dette eksempelet er selvfølgelig ingen allmenngyldig mal. Dere kan likevel bruke det som grunnlag, utbrodere det med egne definisjoner, gå gjennom det jevnlig og videreutvikle det som et levende dokument.

Kilder

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x