Reading time is around 2 minutes. You can also read this online.

---

There's certainly a point when "done" is defined too late. But can you define "done" too early?

Yes, I think so.

A Definition of Done should reduce ambiguity, not create fake certainty. So there's probably a point in your process when you could potentially get ahead of yourselves.

That's when you write rigid acceptance criteria before you understand the problem. You define detailed accessibility behaviour for a flow that may change completely next week, locking in solution details instead of describing the outcome users need. That's how you start adding checklist items nobody can apply yet, so everyone nods and moves on. But deep down you know it's all going to change anyway.

That doesn't prevent any rework.

That being said, I don't think the answer is to wait until the end. That's how you end up debating quality during release pressure.

But maybe there's a useful split here:

• Define stable quality principles early.
• Define feature-specific evidence when the work has enough shape.

So early on you might say that all users must be able to complete the task regardless of what device they use. And later on, you might refine it to include errors that are clear, recoverable and tested with keyboard and screen readers as well as visual.

Somehow, that feels more realistic to me.

Teams rarely know everything up front, so why pretend that they do!? But they can still decide what kind of confidence they need before calling work finished.

That's what "done" is all about.

You don't have to predict every detail, but you can stop your team from moving forward on assumptions nobody has checked.