Rephrase Your Agile User Story & Reframe Your Mindset
Making small but intentional tweaks on how you do things normally can lead to significant impact. Let’s apply this to traditional agile user stories, and watch how they transform and become more impactful.
Traditional User Story Format
In agile, we traditionally write user stories this way:
As a … (user or persona)
I want … (capability)
So that… (user’s goal or need)
It follows the format: User > Capability > User’s Goal or Need
Here is an example:
As a customer service representative, …
I want a shortcut that allows me to access the list of “next best” steps when I enter a specific customer scenario in our CRM system, …
so that I am able to quickly provide the best advise to my customer about their specific scenario.
The Danger with the Traditional Format
The traditional user story format is quite complete already. Many times, however, I see scenarios where the Dev team or the Product Owner already has a capability in mind that they want to implement.
When such is the case, the capability they are creating drives their narrative, instead of the user’s goal or need. As a result, the user’s goal or need becomes an afterthought in the user story, and is therefore not clearly articulated, or has a weak correlation with the capability being built.
Because the traditional format implicitly puts emphasis on the capability to be built, the user’s goal or need usually ends up as:
- half-baked or not clearly articulated
- weakly correlated to the capability being built, and vice versa
- in worst cases, skipped altogether
Examples of Ineffective User Stories
Missing User’s Goal
The worst examples I’ve seen are those that skip the “user’s goal” part. User stories written this way make an assumption that the user’s goal being addressed by the capability is already “obvious”, and therefore, need not be fully articulated. The danger in these cases (i.e., when the user’s goal is not mentioned) is that you do not know if the capability your team is building truly addresses a real user goal or need — one can only assume and hope.
Examples:
As a sales representative, …
I want to get a modal error dialog when we fail to get a response from the remote system.
The above user story has no “user’s goal”. In this case, you can still try to assume that the capability is meant to properly inform the sales rep when a problem occurs — but unless articulated, who knows :)
As a sales representative, …
I want to have a button that lists my tasks in alphabetical order from Z to A.
In the above example, the author is again assuming that the sales rep’s goal & need are obvious. But unless clearly articulated, we do not really know why this capability is needed or worth working on.
Half-Baked User’s Goal
Another set of bad user stories are those with a “user’s goal” but not well articulated. This usually happens when the author just wants to meet the user story format, so they provide anything that sounds valid - but usually end up with something too broad or vague.
Example:
As a survey author, …
I need the ability to optionally hide questions in my survey …
so that the survey authoring experience is awesome.
There are a thousand & one ways to make a survey authoring experience “awesome”. In the above example, there is no clear mapping between the “ability to optionally hide questions in the survey” and what specific awesome experience it provides the survey author.
Changing the Format Changes the Perspective!
The examples above happen because the traditional format puts the “user’s goal” as the last one expressed in a user story.
WHAT IF we can write our user stories in a way that the USER’s GOAL is presented first, and before the capability we are planning to create?
This is how it will look like:
As a … (user or persona)
I want to … (user’s goal or need)
Therefore, I need … (capability)
In this format, User > User’s Goal or Need > Capability, the hierarchy of logical causation is clearer. It enables you to pause and consider what is first & truly important —i.e. the user and their specific goal & need, of course.
When you articulate the user goal first, whatever you specify next as capability or feature must clearly support it, ELSE, the user story will not flow logically. And if the flow from the user’s goal to capability is broken, this new format enables you and your team to spot this easily, and hopefully prompts (or nudges) you to re-consider if the capability you’re creating is truly the correct solution to address the user’s goal or need.
Here’s a summary of this new format.
USER
USER’S GOAL or NEED (the goal/need/pain point that must be resolved)
CAPABILITY (the thing that you will create to in order address the user’s goal/need/pain point)
Let’s revisit our first examples and see them in both traditional format and in this new format.
Traditional format:
As a customer service representative, …
I want a shortcut that allows me to access the list of “next best” steps when I enter a specific customer scenario in our CRM system, …
so that I am able to quickly provide the best advise to my customer about their specific scenario.
New format:
As a customer service rep, …
I want to be able to quickly provide the best advise to my customer about their specific scenario.
Therefore, I need a shortcut that allows me to access the list of “next best” steps when I enter a specific customer scenario in our CRM system.
As you can see, the new format packs a different punch. Since it articulates the user’s goal & need first, you are able to better understand how the capability you’re creating will strongly or weakly support it, or not at all.
Traditional format with a bad example:
As a survey author, …
I need the ability to optionally hide questions in my survey …
so that the survey authoring experience is awesome.
New format with a bad example:
As a survey author, …
I want the survey authoring experience to be awesome.
Therefore, I need the ability to optionally hide questions in my survey
In this bad user story example, you are hard-pressed to ignore the inconsistency or weak connection between user’s goal & capability — which is made obvious in the new format. Hence, it nudges you to rethink if the capability you’re creating is the right solution, or if you fully understand the user’s goal or need in the first place.
In the new user story format:
- You cannot skip the user’s goal or need because it is necessary — it is center-stage to your user story.
- If you have a well-formed user goal, the format allows you and your team to reflect if the capability you plan to build is the right solution to pursue.
- If you a half-baked user’s goal, it will stick out because the flow or logic in your user story will sound incomplete or flawed. And hopefully, this will nudge you & your team to reflect if you truly understand the user’s goal or need.
- It makes sharing your plan with your stakeholders easier. Because you are making them first understand the user’s goal & need, they will better appreciate the capability you are creating.
Caveat: If a team is hellbent on delivering a capability no matter what, no amount of rephrasing can fix the user story or make the team rethink their solution. Hopefully, you have some checks and balances in your development process to prevent this from moving forward.
The Takeaway
Language plays a key role in how we frame our mindset. By rethinking the traditional agile user story, and rephrasing it into User > User’s Goal > Capability, you make the user’s goal or need the driver of the capability you are building. Furthermore, it allows you to rethink if your solution is the right one or if you truly understand the user’s goal & need. A little nudge goes a long way.
Dedicating this article to my father, Rafael Tesoro Nazario, who recently passed away. He had always inspired and motivated me to excel & succeed.
