User Stories Are Not Just for Writing

Before documents, there were stories. Our first tool for shared understanding.

When we look back at human civilisation and how far we have come, one thing becomes clear: every generation has passed knowledge to the next. This knowledge was not only made up of facts. It included daily life experiences, warnings, lessons, observations, and even gossip.

But how did this knowledge survive across generations?

The answer is simple: through stories.

Our ancestors were social beings, just as we are today. Instead of gathering at a pub or scrolling through a phone at night, they may have gathered around a fire and talked about their lives. They shared what they saw, what they experienced, what they feared, and what they learned.

Imagine one person telling their story of seeing bear tracks during a hunt. Another person might add their story about seeing similar tracks in a different area. Someone else might remember hearing strange noises nearby. Through that conversation, the group starts to build a shared understanding: there may be a bear roaming close to their homes.

Someone who was present during that conversation could later share the story with someone who was not there. That person could then pass it on to others. Over time, the story could travel from person to person, and sometimes even from one generation to another.

That is the power of storytelling. Not storytelling as a document, but storytelling as a shared experience that helps people build a common understanding.

Fast forward to today, especially in software development, and we often encounter the word “story” in the form of “user stories.” But somewhere along the way, we seem to have placed too much emphasis on writing perfect, complete user stories. We attempt to capture every requirement, every specification, every edge case, and every detail so that the story can later be referred to by developers, QA, or stakeholders.

Jeff Patton, in his book ‘User Story Mapping’, uses a powerful quote:

“Shared documents are not shared understanding.”

This is where I believe we need to pause and rethink.

Just as our ancestors sharing their stories with others and coming to a shared understanding, ‘user stories’ are also not just for writing and moving on. User stories can also be told, discussed and shared with colleagues so that at the end of the day everyone is on the same page.

A written story can still create many hidden interpretations. Different people may read the same sentence and understand it differently. A developer may interpret it one way. QA may interpret it another way. A stakeholder may have an entirely different expectation.

It is okay to leave some parts in the story open for conversation. There may be things you are not aware of. There may be technical constraints you have not considered. There may be user scenarios that QA or engineering can help uncover. You are not supposed to know everything upfront.

This is exactly why a story that invites discussion is often more valuable than a story that appears perfectly written but is never properly discussed.

So, BAs and product teams, do not be afraid to leave user stories open enough for collaboration. Sit with engineers. Talk to QA. Discuss with stakeholders. Ask questions. Challenge assumptions. Explore edge cases together.

The more you discuss, the more shared understanding you create.

And that is where the user story meets its true purpose: creating shared understanding through conversation.