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.

Specification and Delegation

In any handoff of work, there are two ways for decisions to be transmitted: specification and delegation.

When specifying, the party requesting the work makes a decision and communicates that decision. When delegating, the requesting party conveys intent and authorizes the work-provider to make the necessary decisions on their behalf.

If you aren't getting the results you want out of communicating requests for work - whether it's enablers coming from architects or requirements coming from Product - you have two ways to make it better.

One option is to improve how you delegate. Make an attempt to better-convey intent, give a broad charter to realize that intent, and educate the people doing the work on how to evaluate whether or not they are moving closer to or further from the goal.

Another option is to improve how you specify. Make an attempt to eliminate the potential for misunderstandings in lines of communication, channels that cause information to change hands many times. Install feedback loops to ensure that specifications are met.

While you don't have to choose between getting good at one and getting good at another, do you have to choose one and only one path for any given decision at any given point of time.

That is, you can hand off the specification of a decision you've made or you can delegate a decision to someone else but you cannot delegate a decision to be made exactly as you would have made it.