Definition of ready: hvad skal opfyldes?

Når en produktejer eller interessent opretter en user story, ligger der ofte en klar intention bag. Teamet kan som regel også mærke værdien med det samme. Alligevel ender mange sprint med spørgsmål, afklaringer og små stop, fordi historien ikke var tydelig nok til at blive bygget.

Det er præcis den friktion Definition of Ready (DoR) prøver at fjerne: en fælles aftale om, hvad der skal være på plads, før en story må trækkes ind i et sprint og blive til rigtigt udviklingsarbejde.

Hvad betyder Definition of Ready egentlig?

Definition of Ready er et sæt kriterier, som teamet bruger til at vurdere, om en backlog-post er klar til at blive påbegyndt. “Klar” betyder ikke “færdigbeskrevet til sidste komma”, men “klar nok til at udvikling kan starte uden at gætte på centrale ting”.

En god DoR gør to ting på samme tid:

1. Den skaber en fælles minimumsstandard for kvaliteten af backloggen.
2. Den giver udviklingsteamet et legitimt grundlag for at sige “ikke endnu”, når noget er uklart.

DoR kan ses som indgangen til sprintet. Spejlbilledet på den anden side er Definition of Done, som beskriver, hvornår arbejdet er færdigt og kan betragtes som leveret.

Hvorfor DoR har så stor betydning i praksis

Mange teams tror, at deres udfordringer handler om fart, værktøj eller flere udviklere. I virkeligheden starter en del af problemerne tidligere: i det øjeblik en uklart formuleret story bliver planlagt som “sprint-arbejde”.

Når DoR er tydelig og bliver brugt konsekvent, får du typisk:

• mere ro i sprintplanlægning (mindre diskussion om, hvad opgaven betyder)
• bedre estimater (fordi opgaven er afgrænset)
• færre afbrydelser midt i sprintet (fordi afhængigheder og uklarheder allerede er synlige)
• bedre samarbejde mellem PO, udviklere og test, fordi forventningerne er skrevet ned

En enkelt sætning opsummerer effekten godt: DoR flytter afklaringsarbejdet frem i forløbet, så sprintet kan bruges på at bygge.

Hvad bør en Definition of Ready typisk indeholde?

DoR skal passe til jeres produkt og jeres risici. Et team, der bygger integrationer, har brug for andre “klarhedskrav” end et team, der primært leverer UI-ændringer.

Som udgangspunkt giver det mening at starte med et lille sæt kriterier og udvide efter behov, når I ser mønstre i, hvorfor ting går i stå. En praktisk DoR kan fx indeholde følgende:

• Formål og værdi: Hvem er brugeren, hvad ændrer vi, og hvorfor giver det værdi?
• Acceptkriterier: Hvordan kan vi afgøre, at historien er korrekt implementeret?
• Afgrænsning: Hvad er med, og hvad er ude af scope?
• Størrelse og estimat: Kan den gennemføres inden for et sprint, og er den estimeret?
• Afhængigheder: Er afhængigheder identificeret, og er der en plan for dem?
• Testbarhed: Er det tydeligt, hvordan det kan testes, inkl. data og miljøbehov?

Læg mærke til, at kriterierne ikke handler om at skrive lange dokumenter. De handler om at fjerne tvivl.

DoR og INVEST: en nyttig tjeklinse

Mange teams bruger INVEST som en mental model for gode user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

INVEST er ikke en DoR i sig selv, men den hjælper jer med at stille de rigtige spørgsmål under refinement. Hvis en story fx ikke er “Estimable”, er det sjældent et estimeringsproblem. Det er et klarhedsproblem.

En enkel tabel, der gør DoR lettere at bruge

Når DoR kun står som en liste på en wiki, bliver den nem at glemme. En tabel kan gøre den mere operationel, fordi den kobler kriterier til konkrete spørgsmål og artefakter.

DoR-kriterium	Spørgsmål teamet skal kunne svare på	Typisk dokumentation i backloggen
Mål og værdi	Hvem får værdi, og hvad ændrer sig for dem?	User story-tekst + kort værdi-note
Acceptkriterier	Hvad skal være sandt, før vi kan sige “godkendt”?	Given-When-Then eller punktliste i story
Afgrænsning	Hvad bygger vi ikke i denne omgang?	“Out of scope” linje eller kommentar
Størrelse	Kan vi færdiggøre den i sprintet?	Split af story, hvis den er for stor
Afhængigheder	Hvem eller hvad kan blokere os?	Link til andre tasks, beslutninger, eksterne leverancer
Testgrundlag	Hvilke data, miljøer og checks kræves?	Noter om testdata, logik, edge cases

Tabellen gør det også tydeligt, hvor “klarhed” skal bo: i selve backlog-objektet, ikke kun i folks hoveder.

Sådan passer DoR ind i Scrum og andre agile arbejdsgange

DoR hører hjemme i refinements og i samtalen op til sprintplanlægning. Den skal ikke primært bruges som en kontrol i sidste øjeblik.

Et typisk flow kan se sådan ud:

• Backlog refinement skaber klarhed trin for trin.
• Teamet stiller spørgsmål og beder om præciseringer, før arbejdet bliver “planlægningsklart”.
• Sprintplanlægningen går hurtigere, fordi de fleste åbne punkter allerede er lukket.

Hvis I arbejder kanban-inspireret, kan DoR stadig give mening. Her bliver den ofte brugt som kriterier for, hvornår noget må flyttes til en “Ready” kolonne, så WIP ikke fyldes med halvklar arbejde.

Roller og ansvar: hvem “ejer” at noget bliver ready?

DoR virker bedst som en fælles aftale, ikke som en opgave, der skubbes over på én rolle. Produkt ejerskab og team ansvar skal mødes.

Det hjælper at sige det højt: Produkt-ejeren har ansvar for prioritering og forretningsretning, mens udviklingsteamet har ansvar for at sige, hvad der skal til for at kunne bygge med kvalitet.

En enkel måde at beskrive samarbejdet på er:

• PO bringer intentionen og værdien.
• Teamet bringer spørgsmål, risici, tekniske hensyn og forslag til opdeling.
• Interessenter leverer domæneviden, godkendelser og afklaringer, når der er behov.

Hvis DoR bliver til “PO skal levere perfekte krav”, får I ofte mere afstand og mindre fælles ejerskab. Omvendt, hvis teamet accepterer alt ind i sprintet uden at kræve klarhed, flytter I bare risikoen ind i sprintet.

Tre klassiske faldgruber du kan undgå

DoR kan også blive misbrugt, især hvis den bliver for tung eller for politisk.

Det er typisk her, det går galt:

• Stage-gate tænkning
• Checkliste uden formål
• “Ready” som våben i en skyldkultur
• For mange obligatoriske felter i værktøjet
• DoR, der aldrig bliver opdateret

Hvis I kan genkende flere af punkterne, er løsningen sjældent at droppe DoR. Løsningen er at gøre den mindre, skarpere og mere knyttet til reelle risici.

En handlingsorienteret måde at indføre DoR på (uden at drukne i proces)

Start småt. Få det til at virke. Udvid derefter.

En pragmatisk tilgang kan være:

1. Beskriv jeres 3 mest almindelige “sprint-stop” (manglende acceptkriterier, uklare afhængigheder, for store stories).
2. Skriv 5 til 7 DoR-kriterier, der direkte forebygger de stop.
3. Brug kriterierne aktivt i refinement i 2 til 3 sprints.
4. Justér ud fra konkrete oplevelser, ikke ud fra teori.

Her er et kort eksempel på, hvordan kriterier kan formuleres, så de er lette at bruge i dialogen:

• Klar bruger- og værdibeskrivelse: Teamet kan forklare historien med egne ord på under 60 sekunder.
• Acceptkriterier på plads: Der findes mindst 3 testbare kriterier, inkl. en fejl eller edge case.
• Afhængigheder synlige: Alle kendte afhængigheder er linket eller beskrevet, og der er en aftalt næste handling.

Læg mærke til formuleringerne: de er konkrete, men ikke tunge.

DoR i backlog refinement: spørgsmål der giver klarhed hurtigt

Refinement bliver ofte bedre, når teamet har et fast “spørgebatteri”. Det gør samtalen mere ensartet, også når deltagerne skifter.

Efter en kort intro til historien kan I fx spørge:

• Hvad er den mindste version, der stadig giver værdi?
• Hvad er den mest sandsynlige misforståelse?
• Hvilken afhængighed kan vælte historien, hvis vi ignorerer den?
• Hvad skal testes, som ikke er oplagt ved første øjekast?

De spørgsmål er simple, men de skærer direkte ind til det, der gør en story klar.

Estimering og DoR: derfor hænger de tæt sammen

Et estimat er kun så godt som klarheden bag det. Når teamet estimerer en story, estimerer de i praksis deres fælles billede af opgaven.

Hvis DoR ikke er opfyldt, får I ofte en af to situationer:

• Estimatet bliver oppustet, fordi man “priser” usikkerhed ind.
• Estimatet bliver for lavt, fordi man overser det, der ikke er sagt højt endnu.

DoR er ikke en garanti for perfekte estimater, men det er en stærk måde at reducere den usikkerhed, der ikke skaber værdi.

Hvornår DoR ikke skal være for stram

Der findes opgaver, hvor det giver mening at starte med mere åbenhed. Det gælder især spikes, prototyper og undersøgelser, hvor målet netop er at skabe klarhed.

I de tilfælde kan I have en særskilt DoR for spikes, hvor “klar” betyder:

• hypotesen er formuleret
• tidsboksen er aftalt
• output er tydeligt (hvad skal vi have lært eller besluttet?)

Det gør, at DoR støtter jeres arbejdsmåde, uden at I forsøger at gøre usikker opdagelse til falsk præcision.

Et lille tegn på modenhed: DoR bliver en samtale, ikke et flueben

Når DoR fungerer bedst, kan teamet bruge den uden at kigge i et dokument. Den lever i jeres sprog.

Og når en ny story dukker op tæt på sprintstart, bliver spørgsmålet ikke “kan vi nå det?”, men “er den klar nok til, at vi kan tage ansvar for den i sprintet?”