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

Stop Faking Agile: How to Actually Deliver Faster

Stop Faking Agile: How to Actually Deliver Faster

Almost every company today claims they’re “agile.” They run standups, hold retros, track velocity. The word shows up in job postings, investor decks, and board meetings.

But let’s be honest: In 99% of cases, “agile” is just a buzzword. It’s a label slapped on the same old waterfall process, dressed up with sticky notes and Jira boards.

I’ve stepped into SaaS companies where work still moved in quarterly chunks, QA was a final-phase bottleneck, and priorities were dictated top-down. Nothing about that was Scrum or Kanban — it was waterfall in an agile costume.

Read More
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