The way we think, and the way we use language, have a direct relationship with each other. And a subtle change to the way that we write can change the way we think.
Consider for a moment, one of my favourite topics: goal setting. Let’s take the perennial favourite new year’s resolution:
I want to lose weight.
I will weigh 100kg by the end of this year.
Does one of these seem more real?
The same technique applies when we’re thinking about, and communicating about the work we’re doing in an Agile environment.
Acceptance Criteria tell us when to stop. While I might sound pedantic when I say this, there’s a specific language that I like to use when writing Acceptance Criteria. In short, Acceptance Criteria describe the actual desired state, and not the desire to have some future state.
As a developer or tester, I want to read the criteria and quickly identify whether my solution has accomplished the goals as stated.
So what’s my clickbaity One Simple Trick?
Use the present tense when writing acceptance criteria.
When describing the desired outcome, put your mind into that future state. Write down what the desired state is, and not what it should be.
Why? Using the present tense is a cognitive trick, which changes the way we think about the problem. As a product owner, I can visualize the end state, and easily see gaps in my thinking about the problem. As a developer, I can determine very quickly whether the current state matches the desired state, without parsing out the concept of time.
Here are some examples that I consider good and bad:
- The user should be able to see their account balances at the top of the screen
- The system should display the most recent account balances
- I should write an article about Acceptance Criteria
- Account balances are listed at the top of the screen
- Account balances update when the page is reloaded
- I have posted an article about Acceptance Criterla