Is "Acceptance" a Good Term?

Most of my clients use some variation on agile processes. Most of them use something like stories to define work. They call it different things - tasks, features, work items - but they're all basically the same thing: units of work that need to get done and that provide value to the customers.

In any event, one of the things we do with stories is figure out how we will know when we're done with them. What are the criteria that we'll use to figure that out?

The Acceptance Criteria

The problem is that acceptance implies judgement. The terminology reflects this: "what are the acceptance criteria?" or "does QA accept this?" or "does the customer accept this?"

This is not your QA team

There's a strong implication of judgement and scrutiny going on. Or, if you have kind of a doofus QA team (or product management team), then acceptance is at best a costume parade with a rubber stamp.

This is not your QA team, either.

And neither of those is accurate. When the software development process is working, there's no team or team member sitting in judgement of another. There's no rubber stamp. Instead, there is a collective idea that something is done or not.

Don't accept "acceptance". Let's stop talking about accept and start talking about being done.