Claudio Lassala's Blog

It’s common for conversations in most software teams to center on requirements. “The business needs to give us better requirements. We can’t build the right thing without clear requirements. The requirements keep changing.”

I’ve heard this pattern for years. And I think we’re using the wrong word.

The Limits of Requirements

Requirements suggest something fixed, something handed down. The business gives requirements to developers. Developers ask for requirements. Everyone waits for requirements to be “right” before moving forward.

But here’s the thing: for many projects, requirements don’t actually reflect what will fulfill the need. They’re assumptions about what might work. They’re guesses dressed up as certainty.

And when those requirements turn out to be wrong—which they often do—everyone feels stuck. The business is frustrated because what got built doesn’t match what they needed. The developers are frustrated because they built exactly what was specified.

Stories Get Told and Retold

User stories aren’t requirements either, though we often treat them that way.

Think about it: who wants to tell and retell requirements? Who says, “Hey, I have a great product here—let me tell you the requirements”?

Nobody.

But people do tell stories. “There was a company struggling with employee engagement. They needed their team to change certain behaviors to drive better results. When they started using this tool, their employees shifted how they worked, and the business outcomes improved.”

That’s a story. It gets told. It gets retold. Someone hears it and shares it with someone else: “I heard about this company that had this problem, and it changed when their people started doing this thing.”

Stories spread. Requirements don’t.

Just Call Them Stories

Even the term “user stories” feels limiting. It suggests we’re only telling stories from the user’s perspective. But what about the customer? What about the business? What about the person who has to support the system?

Maybe we should just call them stories. And when we tell those stories, we can be specific: “Let me tell you a story about this business.” Or, “Let me tell you about this customer.” Or, “Let me tell you about this person who was using this product when the following situation came up.”

People, Not Users

Here’s another shift: stop thinking about “users” and start thinking about people.

People don’t wake up excited to spend eight hours in front of a computer using software. That’s not the story they want to tell about their day.

They want to say: “Today a customer came in with a problem. I could see they were worried. I was able to help them, and they left a great review.”

That’s the story. The software is part of the journey, but it’s not the journey itself. People use software to continue their work, to solve problems, to help others. The software is a tool in service of something larger.

When we think about people instead of users, we open up our perspective. We see the full context of their day, their challenges, their goals. We stop designing for “the user who needs to complete task X” and start designing for “the person who is trying to help a customer in a stressful moment.”

Stories as Placeholders for Conversation

A story is a placeholder for conversation. That’s been said many times in the agile world, and it’s true.

Different people hearing the same story will tell it differently based on how it connects with them. That’s expected. That’s healthy.

If people are working on the same project, they need to be able to tell stories that drive similar results. The stories can’t be completely different, but they also don’t need to be identical. Different people will emphasize different parts, notice different details, connect different dots.

Team Ownership Means Telling the Story

In Scrum, we talk about the team owning the story. But to own a story, you have to be able to tell it.

If the team is demonstrating value at a sprint review, can they tell the story? Or are they constrained to having the product owner tell it because the product owner wrote the requirements?

If we shift from giving teams requirements to giving them stories—stories we want the business to tell, stories we want customers to tell, stories we want the people using the system to tell—then we’re in a better position to ask the team to own those stories.

And if a team member owns a story, they need to be able to tell it. Not just say, “Yeah, I’m creating that screen with these buttons and dropdowns.” That’s requirements talk. Tell us the story. How does that screen play a role in someone’s journey? In some company’s success? That’s a more interesting conversation.

Creativity Through Multiple Interpretations

When we tell stories instead of listing requirements, we create space for creativity.

If we present a problem and tell the story behind it, different people will understand and retell that story through their own lens. That means we get multiple ways to possibly tackle the problem.

Someone might tell the story in a way the original storyteller didn’t intend. That different spin might reveal better solutions and opportunities. It might reveal something we hadn’t considered.

Requirements shut down that exploration. Stories open it up.

Using AI to Explore Story Interpretations

With the tools we have now, we can take different interpretations of the same story and have AI create implementations of those interpretations. We can put those in front of people and ask: “Is this the story we want to tell? Which story resonates with more people? Which story will people retell?”

This is about using AI to quickly explore possibilities, to see how different interpretations might play out, to test which stories land.

Human work is still the most important part: understanding the problem, telling the story, and deciding which story matters most.

What Changes When We Shift

When we move from requirements to stories, a few things change:

• Conversations become more collaborative. We’re not debating whether a requirement is “right”—we’re exploring whether a story resonates.

• Teams have more ownership. They’re not just implementing specs; they’re bringing stories to life.

• Flexibility increases. Stories can evolve as we learn more. Requirements feel fixed.

• The focus shifts from outputs (features, screens, buttons) to outcomes (what people can do, what problems get solved).

I’m not saying requirements have no place. Sometimes you need precise specifications—technical constraints, compliance rules, integration details. But those aren’t the starting point. They’re the details that emerge from the story.

The Story We Want to Tell

So what’s the story you want your team to tell? What’s the story you want your customers to tell? What’s the story that will get retold?

That’s where the work begins.