Ma egy olyan eszközt kapsz, ami kezdő Scrum Masterként aranyat ér: a közös „kész” definíciót. A DoD nem dokumentum a fiókba. A DoD egy megállapodás, ami csökkenti a vitát, a visszagörgetést és a rework-öt.

Napi cél (kézzelfogható)

Készítesz egy DoD v0.1-et (7–10 pont) a csapatodnak.
Megtanulod, hogyan építs minőség-kaput úgy, hogy ne „rendőrség” legyen, hanem döntési tisztaság.
Beállítasz 1–2 mérőpontot, amiből látszik, hogy a DoD segít-e (pl. visszagörgetés / hibák / rework).

Mi a DoD valójában?

DoD = közös megállapodás arról, mit jelent a „kész, használható eredmény”.
Miért kell? Mert „kész” nélkül nincs átláthatóság. Ha mindenki mást ért kész alatt, a Review nem tud döntést hozni.
Mit NEM jelent? Nem azt, hogy minden tökéletes. Azt jelenti, hogy a csapat szerint vállalható minőség és ellenőrizhető.

DoD vs Acceptance Criteria (ne keverd)

Acceptance Criteria: az adott work itemhez tartozó elvárás („mit tudjon a felhasználó / milyen viselkedés jó”).
DoD: a csapat minőségi minimuma minden itemre (teszt, review, dokumentálás, deploy készség, stb.).
Gyors szabály: AC = „mit”; DoD = „hogyan ellenőrizhetően kész”.

DoD v0.1 (kezdő sablon)

Válassz 7–10 pontot. A cél: közös minimum, amit a csapat tényleg be tud tartani.

Van tiszta leírás (mi változik, mi a cél).
Elfogadási feltételek vannak (legalább 2–3 konkrét pont).
Megvan az ellenőrzés módja (kézi / automata, ki nézi, mikor).
Kód review megtörtént (vagy páros munka) — minőségi check.
Alap teszt lefutott (minimális smoke / unit / e2e — ami releváns).
Nincs kritikus hiba és nincs „nyitva hagyott” alap kockázat.
Dokumentált a változás (minimum: release note / használati megjegyzés).
Deploy/kiadás szempontból vállalható (visszagörgetési terv vagy safe release mód).

Eljárás: hogyan vezess be DoD-t úgy, hogy ne lassítson

Legyen 2 szint:
- DoD-Minimum (mindig kötelező, 7–10 pont)
- DoD-Plusz (ha a kockázat magas / új terület / kritikus elem)
Keveset változtass egyszerre: v0.1, majd 2 Sprint múlva felülvizsgálat.
Kaput ne „érzésre” tarts: ha a DoD nem teljesül, akkor az item nem „kész” — ez nem vita, hanem definíció.
Mérj: a DoD értéke a csökkenő visszagörgetés és csökkenő rework.

Példák (jó vs rossz)

Példa 1: „Kész, mert működik a gépemen”

Rossz: nincs review, nincs teszt, nincs kockázat jelzés. A csapat csak reméli, hogy jó lesz.

Jó: minimális teszt + review + 1 mondatos release note + rollback terv. A kimenet ellenőrizhető.

Példa 2: DoD túl nehéz

Rossz: 35 pont, amit senki nem tart be → a DoD hitelessége elvész.

Jó: 8 pont (kötelező), + 5 pont „plusz” kockázat esetén. A csapat vállalni tudja.

Példa 3: PO nyomja a gyors kiadást

Rossz: a csapat „kész”-nek jelöli DoD nélkül, majd utána tűzolt.

Jó: a döntés tiszta: vagy teljes DoD, vagy tudatosan vállalt kockázat (külön megállapodással).

Mérőpontok (hogy lásd a hatást)

Visszagörgetés: hányszor kerül vissza „kész” után a munka?
Rework arány: mennyi idő megy javításra ugyanarra a dologra?
Hibák a kiadás után: csökken-e a kritikus hibák száma?

Akció (25 perc): DoD v0.1 megírása

Írj 10 pontot „kész” feltételnek, majd húzd le 7–8-ra (a minimum legyen tartható).
Jelölj ki 3 pontot „plusz” szabálynak (csak magas kockázat esetén).
Válassz 1 mérőpontot (visszagörgetés / rework / hibák), és döntsd el, hogyan fogod rögzíteni 2 Sprintig.

Önellenőrzés

✅ Tudok különbséget tenni DoD és acceptance criteria között.
✅ Van DoD v0.1-em (minimum + plusz).
✅ Van 1 mérőpontom a hatás ellenőrzésére.

Opcionális források

Scrum Guide: Increment + transparency.
Minőség: „build quality in” szemlélet (teszt + review + release hygiene).

Definition of Done (DoD): minőség-kapu, ami nem lassít, hanem gyorsít