What is a user story? Debunking the myths
A user story is not a task, a request, or a requirement; it’s solely a user problem you must work on.
User stories bring value to users
A user story is a small increment of value to the product. Each story should bring value on its own, independently of other stories. Value is created whenever you solve a user’s day-to-day problem (often, you don’t need to code for that). It makes the users happier. For example, “Users can track order status” or “Users can remove their profile photo.” As a counter-example, “As a user, I want to log in” is not a user story as nobody wants to log in just for its sake; it’s something that you have to do to get to it, so it should be done in the context of a real user story.
Beware that the value is only delivered when it’s in the users’ hands and their problem is solved. Talking to users and/or seeing them use the software can help determine if the solution was sound and delivered value.
User stories are not technical
A “tech story” is an oxymoron because if it’s technical, it’s a task/chore, not a story. “Tech stories” are simply tasks masked as user stories. Tasks are developers’ to-dos. They lack a connection with the business. They’ll entangle you in implementation details while losing focus on the real goals. It’s much harder to recognize value because only the developers know the value behind them (if there’s one), which is not inclusive. Any story should connect with the business, and anyone (developer or not, new hire or not) should be able to grasp the goal and user value of any story on the board.
A board filled with technicalities does not encourage constant reprioritization. You can’t decide on urgency based on technicalities — how can you prioritize work when you only see a technical to-do list? You’re not able to make any sense of it.
When pieced together, tasks have a meaning, but that’s not obvious from the technicalities. Tasks are potentially horizontal slices of work — there’s no value until all is done. This promotes leaving things unfinished, requiring lots of coordination and complex feature flagging. Instead, you should encourage vertical slicing, where every thin slice represents releasable value.
Backend or frontend “stories” are not stories; they’re technical tasks. The backend and frontend are technical details.
⛔️ Set cache timeout to 10 seconds
✅ Users are seeing outdated orders
⛔️ Add dropdown to pick a date
✅ Users can't specify the delivery dateAvoid tasks on the board whenever possible. Instead, write the actual reasons. To do it, ask why until you see potential value for the user. A trick I use to write user stories is to think about a world without technology (computers and such). Using pen and paper, users would still want to achieve their goals. Those goals are what user stories should encode. Stick to the domain realm (ubiquitous language), where the user story belongs.
User stories don’t solutionize
A user story (an XP concept) represents a user problem, not a solution. User stories are solely problem statements/reminders. Therefore, you should not think about solutions when creating the user story. You’re wasting time thinking about solutions out of context, far from hands-on. Also, you’re biasing the team towards a solution too early.
⛔️
1. story creation describing the solution
… ⏳ … lots of time has passed
2. hands-on trying to execute the solution
✅
1. story creation describing the problem
… ⏳ … not much time has passed
2. story slicing
3. story kick-off: branstorming and deciding the solution
4. hands-on trying the solution, which can still be pivotedYou’re solutionizing if you’re talking about mouse clicks, screens, or database tables in stories. For example, if you say:
Implement browser-side validation ⛔️
You’re describing a solution, therefore biasing to it.
However, if you write from the users’ perspective, pinpointing their problem:
Users usually commit mistakes when updating their profile ✅
… the team can creatively think about the range of solutions. For example, the team may decide that server-side validation is sufficient. Ideally, they’ll do it at the last responsible moment (they could postpone or discard the story so there is no wasted time).
⛔️ Allow exporting loan data to a spreadsheet
✅ Users want to view the loan summary before confirming
The first solutionizes too soon; it's a feature rather than a problem.
Perhaps the problem could be solved in the app itself.
⛔️ Send SMS with order info
✅ Users want to track their order
The actual problem is enabling users to track their order status.
The possible solutions are many.An engineer’s goal is to move from a real world problem to a real world solution. Just Enough Software Architecture
When creating a story, strive to understand the problem from the users’ perspective. Don’t rush because solving the wrong problem is more expensive. There’s no better way to do it than actually to experience it. Talking to users or seeing them use the software can also help. Going through the same pains yields the best insights.
Leave the how for later; it’s up to the team to decide on solutions only when kicking off the user story. Some teams may solutionize during refinement or preparation meetings, but at least they should ensure they do it after properly defining and splitting the problem.
Beware that the problem and the solution realms can be intermingled because the problem often only becomes clear when we try something and learn from it (i.e., concurrent engineering).
problem realm
what, user story, user goal,
describes users' work, business domain, assumption, experiment️
solution realm
how, tasks, technology, describes teams' work,
design, implementation, delivery, feedbackA user story is not a request or a specification
User stories are not specifications, features, or requirements (otherwise, why not call them requirements?). You should decide on details only when you're hands-on — the last responsible moment. Preparing detailed stories is an antipattern.
Users/clients will often have their premade solutions in mind and hand them to you as change requests. That’s not how it works. You’re supposed to understand the need behind the request and frame it as a problem. User research is critical here. When getting requests, a key question you can ask is, “What problem are you trying to solve?”. You’ll likely find out you could solve it another way (the XY problem). You can discover that the problem is not big and can be postponed.
Ensure you don’t patronize your users; they are in the best spot to help you understand the problem, split it, and prioritize it. All input is valid; you have to understand the need behind the request.
Sometimes, someone in the company (e.g., a business manager, tech lead, or analyst) is doing the thought work and handing off work to the team. Besides this being a central point of failure, pushing work rather than letting the team pull it separates the thinkers from the doers, which is an antipattern. Separating planning and execution is Taylorism, which does not apply to software development. The doers are merely following instructions and implementing requirements provided by thinkers. Engineers and designers are not simple task executors but problem-solvers.
Designers working on a separate board and preparing stories ahead is an antipattern. This is a silo-oriented approach, just like QAs doing testing in a separate lane, which is another example. Splitting work by role is waterfall thinking, leading to work hand-offs. Collaborate instead, focus on work in progress, and help each other to make the stories reach users’ hands.
Anyone from the team can create a story and propose solutions. The team should be autonomous and self-reliant to understand the problem and try solutions. The team needs all the skills and trust required to start with a problem, research it, and solve it. Anything else requires alignment and hand-offs (a waste in lean development). With some access to users, this is much more manageable.
You may wonder how the developers will find out what to do. But why do they need to be told exactly what to do? It took me a while to accept that a user story should not be prescriptive. Often, I didn’t know what to do. It’s comfortable to be spoon-fed, but our jobs are more profound than that. We’re supposed to investigate the problem and consider multiple solutions. This is all discussed and decided when the story starts (ideally as a team or a pair). The whole team should know the domain they work in; they should strive to be close to the users, what problems the users face, actually use the software they build, etc. They should ensure they understand the problem and decide on the solutions at the last responsible moment.
A user story is a promise for a conversation
User stories are placeholders for user problems. A user story describes the user’s work, while a task describes the team’s work. A backlog is not a to-do list; it’s a to-learn list.
User research is supposed to happen so we know the problem we’re solving and to get feedback on the solutions. You should be constantly talking to your users.
Creating stories for developers or product managers (i.e., “As a developer…”) is cheating (unless your users are developers). Ask why a few times, and you’ll probably find the real reason to do it.
A long backlog creates too many promises (also anxiety), so it should be avoided. Also, our perception of the domain changes every time we deliver and hear back from users. Therefore, we strive to have no backlog. Instead, we should put our minds on the present. Talk to the users about the most pressing issue; deliver something small; get feedback; do it in an endless loop. Note that the feedback is not just asking how did it go. If possible, observe the users while they use the software, discuss it while they’re at it, and try it yourself. In a nutshell, get involved.
⛔️ Users don't receive confirmation email
✅ Users can't change their email
Even though the first is not a solution, the second version is better stated
because it mentions the actual problem that users are facing.A user story is an experiment
A story is an assumption until it’s in production, and we learn from it. Every story is a hypothesis, so we want to validate it quickly. This is one of the reasons to make stories as small as possible. We want to keep experiments manageable and bearing low risk.
A user story is solely a user problem stated in one sentence (which is why Post-it notes are enough). Don’t force templates like the Connextra format. Just write a reminder of the problem you set out to solve.
Don’t get attached to user stories. We can always discard or reprioritize them; nothing is written in stone. We can change to a different approach even while working on the story. After delivery, we can still tweak it or revert it. Being able to steer the ship as often as possible should be encouraged.
A user story is light
Creating a new story should be quick, with insignificant overhead, which means you can do it as you split the current user stories and discover the next stories to work on. Just adding the problem statement in the title is enough for most cases. Details are only relevant when starting the work and don’t need to be written down. You may complain that this way, stories are unclear, but that’s part of the goal of a user story. The time to “clarify” the story is when you start work.
This ease with which user stories are created on the fly fosters a culture of experimentation and continuous discovery. More investment creates more attachment, meaning the team will be less inclined to discard a particular piece of work (sunk cost fallacy). A story can be discarded anytime, so little work is lost.
Always remember that the goal is not to finish tickets but to solve problems and make users happier. The tracking tool is just a supporting device; the real work happens elsewhere.
Conclusion
There are different approaches to doing things, and I’ve presented just one of them (revolving around real user stories), but what’s the alternative? Notice that it’s not necessary to implement everything I’ve mentioned in one go. You could start by making small changes in that direction and see how they work out. To wrap it up:
⛔️ A user story is *not* a:
Requirement, Feature, Developer task, Solution, Specification
✅ A user story is a:
User problem, Reminder, Placeholder, Assumption, Experiment
