Auto-Close to Force Better Communication

Recently, I proposed some rules to eliminate ambiguity from acceptance criteria. They centered around the idea of automatically choosing a particular kind of interpretation.

It seems like a powerful tool, replacing decisions with automatic rules. Of course, you don't want to do it all the time...but it seems like a really good way to drive decision-making away from where we don't want it to be, like interpreting acceptance tests.

Another place we don't want judgment calls to be made is at the end of a story/task/work-item. It should be apparent, at that time, whether or not a story is ready to be closed. If it's not, it's already too late.

What if story-closure was automatic?

Imagine a workflow with the following properties.

• Anyone can close a story when all its criteria are met.
• Nobody can close a story if any of its criteria are unmet.
• The strictest interpretation of any given criterion is always enforced by Product, no matter how hard Engineering worked.
• Engineering can reject a story based on insufficient/ambiguous acceptance criteria, no matter how high priority Product says it is.

How would that change the conversation about what to do next, for your team?

Acceptance Criteria as Vehicles for Specification and Delegation

One way to improve the happiness of both Product and Engineering groups is to change the way they communicate to be more validation-centric. Abandon the question "What do we do, now?" in favor of "How will we know when we've done the next thing?"

Anyone paying attention knows that this is a well-traveled topic, so much so that the question "How will we know when we're done?" is basically a cliché in the software industry. Nevertheless. It's my turn to say it.

Get rid of detailed instructions, descriptions, and design documents. Replace them all with acceptance criteria.

After all, what else matters? How useful is a design document that you can't use to tell whether or not you're done? If you have an instrument that tells you that, what's the value in the other documents?

If you can get good acceptance criteria - really, truly, good ones - you can drive noise out of the communication lines between Product and Engineering. It goes further than that, but fixing the (usually) broken handoff between those two organizations yields enough value on its own to justify the change.

Agreeing with this post is the easy part. Making the change is the hard part. There's a social aspect to it and a skills aspect to it.

In the latter category is a hard question:

How do we get really good acceptance criteria?

More on that to come.