Defining Done

Acceptance criteria and the importance of recognizing the pass/fail conditions.

Defining Done

When I was at Pivotal, I learned about acceptance criteria as a way to define work and align on expectations.  

The acceptance criteria defines the done state. It's similar to the concepts of Test Driven Development, where you write the test, make it fail, then write the code that will make it pass. When it passes, you're done with that feature.

In practice, this isn't that different from setting goals and working backwards.

The critical difference is in the fail state. If you don't define how a task, objective, feature, or goal might fail, then it's difficult to articulate the success state.

To define the success state, you might be familiar with specific and measuable goals. They serve to evaluate the success and fail state of the goal.

For example: I want to read 100 books a year. 99 books a year is technically a fail. 100 books a year is a success.

What about goals that don't have metrics? This is where acceptance criteria comes in: Given/When/Then. Given a situation, when I do x, I expect y.

Our ability to define x and y is what's critical. The action and expected output. It answers the question: when are you done?

What's the fail state?

The next time you come across a goal or objective that's being defined. See if you can name a failing case. Under what circumstances would this be considered incomplete or not done? If I read 90 books a year, is that success? When the done state isn't clear, the goals aren't clear.