The Missing Piece in Your User Stories

(And Why It Matters)

Are Your Engineering Efforts Truly Delivering Value?

As engineers working in agile environments, we live and breathe user stories. They are the fundamental building blocks we use to understand what needs to be built. But often, a crucial part of the story gets left out, leading to wasted effort and a disconnect between our work and the actual value it was supposed to deliver.

What Exactly is a User Story?

Originating in Extreme Programming (XP) and now a staple of most agile frameworks, a user story is a simple, informal description of a feature told from the perspective of the person who wants that feature. It's designed to shift the focus from rigid, technical requirements to understanding the user's need.

A common format you'll see is ISBAT, which stands for "I Should Be Able To. For example:

As a [type of user], ISBAT [an action] so that [a benefit or goal].

The Crucial Missing "So That"

In my experience as an Agile Coach, I've observed that a LOT of user stories I encounter are missing the "so that [a benefit or goal]" part. Product owners and teams often write stories like:

• "As a user, I want to log in."

• "As an administrator, ISBAT create new user accounts."

• "As a customer, I want to add an item to my cart."

While these tell us who wants what, they completely omit why.

Why the "So That" is Non-Negotiable

Leaving out the "so that" is a critical oversight. The benefit or goal is the value proposition of the user story. It's the crucial link that translates the business or customer need into something the engineering team can truly understand and build effectively.

Without the "so that":

• Prioritization is based on guesswork: How do you know which story is more important if you don't know the value each delivers?

• Decision making is less informed: The team lacks the context to make the best technical and design choices. They might build something that technically fulfills the "what" but fails to achieve the intended outcome.

• Measuring success is difficult: How do you know if the story is truly "done" and successful if you don't know what benefit it was supposed to provide?

• Motivation can suffer: It's harder for engineers to feel connected to their work when they don't understand the positive impact it will have.

The "so that" provides the necessary context for technical interpretation. It allows engineers to think about the underlying problem and potential solutions, rather than just implementing a requested action blindly.

6 Categories for Defining the Value: Beyond Just Revenue

While revenue is a business goal, simply stating "so we can make 1 million dollars" in a user story is rarely helpful. The "so that" should explain the specific user benefit or operational improvement that leads to business outcomes.

Here are some categories of value to consider when defining your "so that" clause:

🔹 User Efficiency / Productivity

How does the feature save the user time, effort, or reduce errors?

As a online shopper, I want to save my payment information, so that I can complete future purchases faster.

🔹 User Satisfaction / Experience

How does the feature make the user happier, more confident, or the system easier to use?

e.g. As an online shopper, I want to see clear error messages, so that I understand what went wrong and can communicate it to customer service.

🔹 Business Efficiency / Cost Reduction

How does the feature improve internal processes or lower operational costs?

e.g. As an site administrator, ISBAT automate report generation, so that our team saves 10 hours per week on manual data compilation.

🔹 Risk Reduction / Compliance

How does the feature mitigate risks or help meet regulatory requirements?

e.g. As a shopper, I want two-factor authentication, so that my account is more secure against unauthorized access.

🔹 Increased Engagement / Adoption

How does the feature encourage users to use the product more or for the first time?

e.g. As a new shopper, I want an interactive tutorial, so that I can quickly understand how to use the core features.

🔹 Learning / Knowledge

How does the feature provide the user with valuable information or insights?

e.g. As a site manager, I want to see site usage statistics, so that I can track progress towards my goals.

Finding the "So That"

If you're struggling to define the value, ask these questions from the user's perspective:

• What problem does this solve for me?

• How will my life/work be better after this is implemented?

• What pain points will be removed?

• Why would I choose to use this feature?

• What is the ultimate goal I'm trying to achieve?

And from a business perspective, consider:

• How does this user's action contribute to a business goal (like increased revenue, reduced cost, improved retention, etc.)? Connect the user's benefit to the business outcome.

Make the "So That" a Habit

Insisting on a clear "so that" in every user story might feel like extra work, but it’s crucial in ensuring you are building the right thing and it pays dividends in the long run. It aligns the team around shared goals, leads to better-designed features, and ensures that your engineering efforts are truly focused on delivering tangible value to both your users and the business.

So… if find yourself guilty of omitting the value in a user story, start incorporating the "so that" into your user story writing using the 6 categories and questions. You’ll quickly see the difference it makes.