Always Lead With Context

Contextless Acceptance Criteria Quickly Become Noise

Imagine you’re provided with the following text:

“The procedure is actually quite simple. First you arrange things into different groups depending on their makeup. Of course, one pile may be sufficient depending on how much there is to do. If you have to go somewhere else due to lack of facilities that is the next steps, otherwise you are pretty well set.

It is important not to overdo any particular endeavor. That is, it is better to do too few things at once than too many. In the short run, this may not seem important, but complications from doing too many can easily arise. A mistake can be expensive as well. The manipulation of the appropriate mechanisms should be self-explanatory, and we need to not dwell on it here.

At first the whole procedure will seem complicated. Soon, however, it will become just another facet of life. It is difficult to foresee any end to the necessity for this task in the immediate future, but then one can never tell.”

After reading you’re probably thinking: what the hell did I just read?

This is actually a snippet from a real-world science experiment done in the 70s. Participants in the experiment were secretly divided in 3 groups:

1. Context not provided

2. Context provided after reading the text

3. Context provided before reading the text

These three groups all received exactly the paragraph you just read (except it was a recording). Afterwards, the participants were rated on comprehension (do they understand what was written?) and recall (do they remember what was written?).

Group 1 and 2, did not score significantly different on comprehension and recall. No context or providing the context after they’ve heard the passage didn’t make a huge difference. Group 3 scored the best. Providing the context before, almost doubled the comprehension and recall scores.

The paragraph was actually about something as simple as washing instructions. What does this mean for how we work with our teams?

Context is King

It’s pretty simple: always start with providing sufficient context and why. Assume a new team member has joined and they completely lack sufficient context. Whenever I join a new team, I look at the Product Backlog Items as someone who just joined the team and knows very little, and I check if they’re sufficiently anchored in context: what problem are we trying to solve and why does it matter?

By providing the context first, we activate a schema. The exposure of a prior stimulus influences the response to a subsequent stimulus. This means that the information is anchored in something they already know.

You’d be surprised how few Product Backlog Items pass this test. Telling the context afterward simply isn’t good enough.

Soak your Product Backlog Items with context first, because that’s the foundation for everything else that follows. It works for something as simple as washing instructions, and it’s even more important for all the complex things we’re trying to achieve.

If you’re not providing context, you’re robbing your team of the opportunity to remember, recall and even challenge what we’re trying to do. You give them the option to even potentially reframe the problem into something more valuable.

If you do nothing else, begin with context. That’s how important it is to whatever you’re trying to do. And providing it at the end just won’t cut it.