The No-Nonsense Definition of Ready & Definition of Done

Post image
Ready means ready. Done means done. No excuses.

Most agile teams say they use a Definition of Ready (DoR) and Definition of Done (DoD). In practice? They’re often ignored, overcomplicated, or so vague they don’t help anyone.

Over the years, I’ve refined a lean, practical version of both. It’s sharp enough to be useful across companies and simple enough that people actually use it.

The No-Nonsense DoR

A story is ready when:

  • Story makes sense and has a clear goal
  • Acceptance criteria are testable
  • No major unknowns (unless it’s a research)
  • Small enough to finish in one sprint
  • Nothing blocks
  • Risk is known and manageable
  • Epic & Components linked
  • Architect says yes
  • PO says yes

If you can’t tick these boxes, the story isn’t ready to take on. Period.

The No-Nonsense DoD

A story is done when:

  • Stuff actually works (not just in a slide deck)
  • Provides a running, testable software increment
  • Tests are green
  • Security is green
  • QA (Sonar) is green
  • Someone else has reviewed it
  • It’s deployed to test

That’s the baseline. No excuses, no “almost done.”

Why This Works

  • Clear and binary
    Ready or not. Done or not. No wiggle room.
    The checklist removes subjective debates and makes decisions fast — either it passes or it doesn’t.

  • Stops waste early
    DoR prevents half-baked stories from entering sprints. DoD prevents half-baked software from leaving them.
    Catching problems at the gate saves far more time (and pain) than finding them mid-sprint or after release.

  • Balances speed and quality
    Both lists are lean. They enforce standards without bogging down delivery.
    Instead of slowing velocity, they create a rhythm where quality becomes automatic rather than an afterthought.

  • Reusable baseline
    Teams can extend them – but this minimum set works everywhere.
    By starting with the essentials, you get consistency across teams without falling into the trap of over-engineering.

Closing

A good DoR and DoD aren’t bureaucratic checklists. They’re guardrails: simple, repeatable, and impossible to argue with. Together, they save time, prevent endless debates, and keep teams focused on delivering working software.

That’s my no-nonsense DoR and DoD.

You May Also Like

If pragmatism raises technical debt, call it oversimplification (rant)

If pragmatism raises technical debt, call it oversimplification (rant)

The word “pragmatism” or “pragmatic” is, in my personal opinion, the most overrated word in agile development. Many people use this as a buzzword without knowing what it means. I hear people saying “He solved that complex problem in half an hour, he’s so pragmatic!” and think for myself “Yeah, but that ‘solution’ probably causes other devs three times more effort than a sustainable solution would take.”

Read More
How to Map Your System Landscape in One Afternoon – The C1.5 Shortcut

How to Map Your System Landscape in One Afternoon – The C1.5 Shortcut

You’ve just stepped into a new role – maybe as CTO, maybe as Head of Development – and as usual, the architecture is a maze or even completely missing. Documentation is outdated, knowledge is scattered, and no one holds the full picture. Without a map, you’re flying blind.

You could spend weeks reading thru confluence, readme and code, piecing things together, but there’s a shortcut:

In this post, I’ll show you how to map a “good-enough” system landscape in one afternoon using a lightweight, practical shortcut of the C4 framework I call C1.5.

Read More