Definition av klart: exempel, checklista och workshop i Scrum

Häromdagen förberedde jag en workshop tillsammans med en kollega. Vi kom snabbt överens om innehållet, det enda som saknades var en lämplig PowerPoint-presentation. För att kunna arbeta med presentationen så effektivt som möjligt delade vi upp den tematiskt. När vi sedan satte oss ner för att diskutera det färdiga utkastet blev ett stort problem uppenbart: vi hade väldigt olika idéer om vad som faktiskt kännetecknar ett “färdigt utkast”. 

Detta problem kan också uppstå i agila Scrum-team. Efter två veckor når teamet slutet av sprinten, men det råder oenighet om huruvida produktinkrementet redan är färdigt och kan flyttas från “in progress” till “done”. Denna oenighet leder till diskussioner, som i sin tur påverkar klimatet i teamet negativt. För att förhindra dessa diskussioner och för att skydda ett effektivt teamarbete finns det en artefakt i Scrum-världen som kallas “Definition of Done” (DoD). 

Vad är Definition of Done i Scrum?

Definition of Done är Scrum-teamets gemensamma kvalitetsöverenskommelse. Den beskriver vilka villkor som måste vara uppfyllda för att ett inkrement ska räknas som färdigt och användbart. Det är inte en personlig uppgiftslista och inte en extra granskning av en enskild roll, utan en transparent standard för hela teamet.

Definition of Done betyder bokstavligen “definition av färdig”. Det innebär att teamet kommer överens om vad som måste göras för att en funktion ska anses vara färdig. I praktiken kan Definition of Done beskrivas som en slags checklista som används under sprinten och särskilt i slutet för att kontrollera om vissa kriterier för färdigställande har uppfyllts. För programvaruutvecklingsteam kan dessa kriterier till exempel vara följande: 

Definition av klart exempel: checklista för Scrum-team

En praktisk Definition of Done kan till exempel innehålla följande kriterier för en mjukvaruprodukt:

• Acceptanskriterierna och de funktionella kraven är uppfyllda.
• Dokumentation har upprättats.
• Koden är fullständigt genomförd och kommenterad.
• En kodgranskning genomfördes.
• Automatiserade tester körs успешно; relevanta fel och säkerhetsrisker har åtgärdats.
• Ändringen är integrerad och kan verifieras i en produktionsnära miljö.
• Övervakning, loggning och vid behov release notes har beaktats.
• Inkrementet är användbart och uppfyller produktens kvalitetsstandard.
• …

Den här listan är ett exempel, inte en universell mall. En bra DoD skyddar kvaliteten, förblir tillämpbar för teamet i varje sprint och justeras när produkt, risker eller tekniska förutsättningar förändras.

Definition of Done är inte samma sak som produkteffekt

En Definition of Done besvarar en viktig fråga: Uppfyller inkrementet den överenskomna kvalitetsstandarden och är det användbart? Den besvarar däremot inte automatiskt om ändringen på marknaden eller hos kunden ger den önskade effekten.

För praktiken hjälper därför en åtskillnad mellan tre nivåer:

• Done: Inkrementet uppfyller Definition of Done och kan användas.
• Done-Done: Ändringen är integrerad, levererad och observerbar i drift.
• Produkteffekt: Verklig kundfeedback visar om ändringen löser ett relevant problem och ökar produktvärdet.

John Cutler beskriver därför mjukvara som ett kontinuerligt vidareutvecklat servicesystem: funktioner är inga slutgiltiga byggnader, utan tillfälliga medel för att skapa kundnytta. Läs hans perspektiv i The Work Is Never Done.

Gil Zilberfeld skiljer dessutom mellan olika betydelser av “Done” – till exempel när utveckling, tester, leverans eller kundfeedback var och en markerar en annan grad av färdigställande. Hans tolkning hittar du i The Definition of Done, Done-Done and Really Done.

Viktigt: “produkterffekt” bör inte bara formuleras som ett extra DoD-kriterium. Ett Scrum-team måste leverera ett användbart inkrement; om det ger den önskade effekten blir därefter synligt genom Sprint Review, användning och fler lärandeloopar. Just den här uppdelningen skyddar Definition of Done från att bli en ouppnåelig samlingslista.

Hur Definition of Done samspelar med andra verkningsfulla Scrum-praktiker visar vi i vårt inlägg Scrum Best Practices 2026.

Varför är en definition av “Done” viktig?

Att målsättning är av enorm betydelse för prestationen är ingen ny insikt. Målsättning är ett mycket utforskat ämne inom psykologin (jfr. Locke & Latham, 2006). Det har visat sig att prestationen är som högst när målen är så specifika och utmanande som möjligt utan att verka ouppnåeliga. Definition of Done är dock inte en metod för målsättning (men om den ska användas är det en metod för att sätta upp mål). Stöd med målsättning Om du behöver hjälp hjälper vi dig gärna); det är snarare en fråga om kriterier som måste uppfyllas för att uppnå målet. 

Dessa kriterier är viktiga för att skapa en gemensam förståelse i teamet. En förståelse för vad varje teammedlem måste uppnå för att nå det gemensamma målet. Det handlar alltså om individuella prestationer som i slutändan leder till en lagprestation.

Om vi ser på frågan om DoD ur produktägarens synvinkel framträder helt andra problem. Om det inte är klart definierat när ett produktinkrement anses vara färdigt, kan det leda till oenigheter med kunden när produkten presenteras för honom. Om detta inträffar och en ofärdig produkt presenteras blockeras möjligheten till återkoppling från kunden. 

Kontinuerlig förbättring

Eftersom en Definition of Done inte är ett statiskt koncept utan ständigt kan och bör utvecklas eller förändras, ger den också teamet möjlighet att lära sig. Om teamet i slutet av en sprint inser att det inte kunde uppfylla kriterierna i Definition of Done kan teammedlemmarna antingen justera Definition of Done så att den motsvarar det faktiska resultatet, eller så drar teamet slutsatser inför nästa sprint och ändrar sitt eget arbetssätt.

Testa Echometer gratis nu och få ny inspiration till dina retrospektiv!

Kostnadsfritt test av Echometer

Dessa reflektioner kring Definition of Done bör göras av teamet under retrospektivet. Möjligt Echometer Artiklarsom kan ställas som förberedelse, är följande 

Vi har tydliga definitioner av våra krav.

Jag brukar veta var vi står när det gäller att uppnå våra gemensamma mål.

Målsättningar: Mina mål ligger i linje med mina kollegors mål.

Teamet täcker alla de färdigheter vi behöver för att uppnå vårt mål.

De ifrågasätter inte bara om det överhuvudtaget finns en Definition of Done i teamet, utan också hur transparens, autonomi och rollklarhet ser ut i teamet.

Du hittar den fullständiga artikelpoolen i vår Retro-verktyg.

Hur kan vårt team definiera vad som är gjort? Ett exempel på en workshop

Vi har visat vad en Definition of Done är och varför den är viktig för ett effektivt samarbete i Scrum-team. Men om ditt team inte har skapat en DoD ännu undrar du förmodligen hur det fungerar. 

I princip är det viktigt att teamet tar god tid på sig när det utarbetar dokumentet. I slutändan bör det finnas ett dokument som varje teammedlem kan identifiera sig med och som inte bara ses som ett nödvändigt ont. Därför rekommenderar vi ett workshopliknande format med Scrum Master som moderator. Varje teammedlem bör fundera på vilka kriterier som är viktiga för att slutföra produkten och teamet kan sedan sammanfatta dessa tankar. På samma sätt har vi utvecklat ett workshopformat för målsättning. Ta en tittför att få idéer till din workshop om Definition of Done! 

Den färdiga DoD kan användas i retrospektiv, till exempel i form av trafikljuset Definition-of-Done:  

1. Skriv dina kriterier för definitionen av Done under varandra.
2. Rita en röd, en gul och en grön kvadrat bredvid varje kvadrat.
3. För varje punkt i Definition of Done markerar varje teammedlem om den implementerades bra, måttligt bra eller dåligt under den senaste sprinten. 
4. Diskutera de tre som oftast nämns i det röda området.
5. Justera din definition av färdig vid behov.

Slutsats – Färdigt?

Några avslutande ord: Det finns inget som heter “färdigt” i den agila miljön. Klart betyder bara att något är preliminärt färdigt, men ytterligare justeringar och förbättringar kan och bör följa när som helst. Detta är en av de många vackra aspekterna av agilt arbete: kontinuerlig förbättring. 

Särskilt spännande: Ibland är en punkt “klar” tills kunden kommer fram och ifrågasätter hela lösningen och därmed skakar om din grund av antaganden om kundens behov. I sådana situationer blir det tydligt om teamet verkligen har prioriterat kundnyttan framför framstegen i ärendehanteringssystemet.

En tydlig definition av vad som är gjort kan undvika konflikter och öka din prestation. Om du är intresserad av fler sätt att uppnå detta mål bör du också ta en titt på vår artikel om den fantastiska sanningen bakom det agila tankesättet titta. Eller berika dina tillbakablickar genom att ta hänsyn till de senaste vetenskapliga rönen inom psykologi.

Exakt med detta löfte har vi utvecklat vårt retroverktyg Echometer. Om du är intresserad av hur (och om) Echometer fungerar, läs gärna Holgers erfarenhetsrapport med vårt verktyg:

Vill du ta ditt team till en ny prestationsnivå? Vårt retroverktyg kan hjälpa dig att göra det. Här är Holgers erfarenheter av det:

Holgers erfarenhetsrapport om Remote Retro Tool

Vanliga frågor om Definition of Done

Vad ska ingå i en Definition of Done?

I en Definition of Done ingår alla kvalitetskriterier som ett inkrement måste uppfylla för att vara användbart. Typiska exempel är uppfyllda acceptanskriterier, kodgranskning, tester, säkerhetsgranskning, dokumentation och den tekniska möjligheten att leverera. Vilka punkter som gäller avgör teamet utifrån sitt produktkontext.

Vem skapar Definition of Done i Scrum?

Scrum-teamet utvecklar och förvaltar Definition of Done tillsammans. Den bör inte vara påtvingad av en enskild roll som en kontrollista. Organisationer kan sätta minimistandarder, men teamet måste förstå dem och kunna tillämpa dem i vardagen.

Vad är skillnaden mellan Definition of Done och Definition of Ready?

Definitionen av Done beskriver när ett inkrement är färdigt och användbart. En Definition of Ready kan däremot innehålla kriterier för förberedelsen av ett arbetsobjekt, men är inget officiellt Scrum-artefakt och får inte användas för att skjuta ansvar eller feedbackloopar framför sig.

Exempel från praktiken: Vår interna Definition of Done hos Echometer

En Definition of Done måste inte sluta vid kod och tester. Echometer använder internt en mer omfattande standard som, utöver funktionalitet, även tar hänsyn till UX, underhållbarhet, observerbarhet och förberedelsen av releasen. Följande exempel visar hur ett team kan göra sina egna kvalitetskriterier konkreta och verifierbara:

Område	Exempel på kriterier
Funktionalitet	Den specificerade funktionen fungerar, typiska edge cases är testade, det finns inga kända fel, ofärdiga funktioner är skyddade med feature flag och relevant användningsdata samlas in.
UX	Tomma lägen, laddningslägen, behörigheter, felhantering, lokalisering och responsiv visning är beaktade.
Underhållbarhet	Coding Guidelines och relevanta konventioner följs, onödig kod och medvetet lämnad teknisk skuld har undvikits, och viktig information för övervakning och felsökning finns tillgänglig.
Driftsättning	Förändringen har rullats ut till produktion eller medvetet förberetts via feature flag, release notes har kompletterats och berörda intressenter informeras vid behov.

Det här exemplet är förstås ingen allmängiltig mall. Ni kan dock använda det som grund, bygga ut det med egna definitioner, granska det regelbundet och vidareutveckla det som ett levande dokument.

Källor

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