The line you quote is oddly one of my strongest arguments against Scrum.

Agile in general and Scrum in particular don’t want to declare things as done when they aren’t and if you haven’t yet given feedback, is it really Done? I don’t think it is.

With Scrum the pressure to put away the done thing and start something else is very high. The moment you start thinking about your next story, unless it’s very closely related to the previous, your ability to accept feedback becomes quickly curtailed.

This is half of the point of Continuous Integration. Fast feedback is often the only feedback that causes behavioral changes. Things that happened a while ago become abstract. Think about a conversation you’ve seen where someone describes how another person hurt their feelings yesterday, versus five years ago. The reactions are very different.

So if you enjoy talking, I suppose it “works” for you but if you hate having to give the same correction over and over, you need to make the person stop and go back until they learn how not to get stopped. Anything else loses the war.

In my teams, I try to pre-empt as much as possible by getting feedback from users on mockups. And then the item is "done", only when product verifies the core flows before it goes to production. I don't do Scrum/sprints (I think it puts artificial timelines and unnatural item splits) , but more aligned with Kanban (this gives me never-ending grief about quarterly releases, QBRs etc, but thats another story). So we try to make what's "done" fairly well defined. Does this slow down shipping? A little bit. But in practice, we end up shipping something at least a couple times a week.

We used to play a bit fast-and-loose with what's defined as "done", and that allowed us to ship everyday, but the loose part of that invariably came back from our customers, at a much higher cost. So we went back to being a little more rigorous.