How a better user story can prevent you from being buried alive (in the way you want)

As told in the excellent book A Whack On The Side Of The Head by Roger von Oech, a few centuries back there was a plague in a small village that caused people to go into a death-like coma. Most of them eventually died, but occasionally someone would be mistaken for dead and accidentally buried alive.

When the villagers discovered this, they started working on a solution…

Two groups came up with very different solutions to the problem. Von Oech uses the story to show the benefit of thinking outside the box and coming up with multiple “right” answers. ¹

However, I think the story can be used as a great lesson on why it is so important everyone on your team understands what problem you are solving and why.

A user story refresher

Most commonly, user stories are written in this format:

As a [role], I want to [goal], so that I can [reason]

or in the short form (which makes for easily scannable story titles in a ticketing system, btw)

Role – Goal – Reason

The format helps teams go beyond simple requirements (the goal portion) and understand the persona with the goal and the reason behind the goal.

And I must revise what I said above. This is the most commonly recommended format. The most commonly used is a little different.

Over time, many teams start to leave out the reason. And it is understandable. Teams are busy and that extra 20-30 characters per story could save them literally dozens of seconds per day.

In reality I think teams start to omit the reason because they assume the reason is obvious. Or they assume that everyone on the team has the same understanding of the reason, so there is no benefit to writing down what everyone already knows.

The danger, of course, is that when you are working in a complex domain where there are multiple right answers to any given problem, if your team doesn’t have shared understanding, they may not be solving the same problem.

Back to the village

To express the needs of our villagers in the form of a user story while omitting the Reason portion:

As a villager, I want to prevent people from being buried alive…

When the villagers returned from their 18th century brainstorming session, they had two proposed solutions.

Idea 1

The next time they buried someone, they would put food and water in the casket and make an air hole to the surface. This would be expensive and complicated, but would solve the problem.

Medical technology being what it was at the time, they couldn’t easily verify the person’s state before burial, so the couldn’t technically prevent the person from being buried, but they thought this idea would help.

Idea 2

The second group came up with a much simpler solution that satisfied the user story.

They put a twelve inch long stake in the lid of the coffin, ensuring that the person inside would be would always be dead shortly after the lid was closed.

You’ve got to love pragmatism.

How this looks in modern times

Have you ever been in a team meeting where the product owner and a developer have a vigorous debate about how a feature should be built?

I’ve seen many a backlog refinement or design meeting where a well-meaning but pragmatic developer explains how they will meet the requirements of the story while the product owner sits there aghast, as though the developer just proposed putting a spike into the lid of a coffin.

Then ensues a long (and potentially heated) discussion about the merits of each proposed solution. And it is only when both sides come to a shared understanding of the “why” behind the story that progress can be made. Because until “why” is known, the team members aren’t working on the same problem.

And that is the key. Without the “why” being documented, discussed and understood, the problem isn’t defined and the story isn’t ready to be worked.

Don’t forget the “Why”

Both of the villager’s proposals satisfy the story as written.

However, if you add in the reason, you get a different result.

As a villager, I want to prevent people from being buried alive, so that we can save as many lives as possible

And as von Oech notes:

Whereas the first group asked “What should we do in the event we bury someone alive,” the second group wondered, “How can we make sure everyone we bury is dead?”²

If only they’d included the reason in their user story they could have saved not only confusion but a few coffin-spikings as well.

Shared understanding

As I think about it, nearly all parts of an agile team’s process are designed to create shared understanding.

• We involve customers and stakeholders early and frequently to understand their needs
• We meet daily in standups to create a shared understanding of how we’ll tackle today’s work and what impediments we might have
• We use planning poker and story points to ensure we all equally understand the details and complexity of our work
• We demonstrate working features to get feedback so that we better understand if we’re headed in the right direction or need to course-correct
• We hold retrospectives to make sure that what is working and what isn’t is understood by the whole team

In that context, including the reason in user stories simply makes them consistent with the intent of the rest of the agile process.

This is something I’ll be thinking about going forward. Are we building something the user wants, or are we inadvertently creating a coffin-spike?