Why Is Writing a Good User Story So Hard?

It sounds simple

I’ve worked with a lot of product managers, designers, developers and QA engineers, and it still surprises me how hard it is to write a good user story. On paper the job is small: describe what the user needs, explain why, and define what success looks like. There’s even a familiar format for it: as a user, I want to do something, so that I can achieve some outcome.

If it were that simple, teams wouldn’t spend so much time discussing requirements, rewriting tickets and discovering missing details halfway through development. I don’t think the problem is that people don’t know the format. Everyone approaches a feature with different knowledge, experience and assumptions, and it’s easy to forget that other people don’t know what we know.

Writing a good user story is hard because product managers, designers, developers and QA each approach a feature with different knowledge and assumptions, and the story has to give all of them the same understanding. A story written from only one of those perspectives leaves everyone else guessing.

Everyone sees the feature differently

A product manager might understand the business problem extremely well and know little about how the software works. A designer understands the user journey and the interaction, and may not know the technical constraints behind the interface. A developer knows the architecture, the database and the APIs, and may not fully understand the business objective. QA knows how to test the application, and may not know which business rules were included or left out on purpose.

None of that means anyone is bad at their job. People specialize for good reasons. The trouble starts when we expect one person to write a story that everyone else can understand without further discussion. Not everyone has worked across product, design, engineering and operations, and those of us who have still have gaps. So writing a user story involves more than documenting requirements. It’s an exercise in building shared understanding, which is the same idea behind not expecting everyone to know everything.

We also tend to write stories in the language we know best. Developers describe features in technical terms, product managers describe business outcomes, designers describe screens and interactions, and QA describes conditions and expected results. A developer might write “Implement a new API endpoint to update the customer record and invalidate the Redis cache.” Another developer knows what to do. The product manager can’t tell what business behavior it supports, and QA can’t tell what the customer should see. A product manager might write “Users should be able to manage their account information easily.” The intent is clear, and the developer still has to work out which information, which permissions and what happens when something goes wrong. Both stories carry useful information, and neither gives the team a shared understanding on its own.

I don’t expect everyone to become an expert in every discipline. I do expect people to recognize where their knowledge ends and someone else’s expertise is needed.

Too much detail, or too little

I’ve seen user stories that run several pages. They describe every button, every interaction, every condition and sometimes how the code should be written. It looks thorough. In practice it becomes hard to tell what we’re trying to deliver. Is it one feature or five? Which parts are essential, what can ship first, and what depends on something else? How do we know when it’s done? Without a clear breakdown of the user journey, a long list of requirements turns into something to interpret. Developers spend time decoding the document, QA can’t find the boundaries of what to test, and product struggles to say what’s ready for release. More detail doesn’t automatically create more clarity. Sometimes it just creates more to manage.

The opposite happens just as often. A story says “Allow users to update their profile,” and nothing else. The developer is left to decide which fields can change and which can’t, what validation applies, what happens when the save fails, whether changes take effect immediately, who has permission, and whether the user sees a confirmation. If nobody answers those questions, the developer makes reasonable assumptions and may build something that works technically and misses the business need. The team then spends time correcting it, and the real problem was never the implementation. We never agreed on what to implement.

Too big, too small, or a task

I encourage teams to write smaller stories, because smaller stories are easier to develop, review, test and release. I made that case in smaller user stories and pull requests. Smaller doesn’t automatically mean better, though. “Create a submit button” is small, and it leaves the developer guessing what the button submits, what validation runs and what should happen afterward. “Build the entire customer onboarding experience” sits at the other end. It could include registration, authentication, profile creation, document uploads, eligibility checks, notifications and approvals, which makes it hard to estimate, build or test as one piece.

What works better is understanding the whole user journey first, then finding meaningful pieces that can be delivered independently or in a sensible order. A good story is small enough to deliver and complete enough to understand.

A user story is different from a technical task. A story describes something a user can accomplish and why it matters. A database migration, an API endpoint and a React component might all be necessary tasks to deliver it, and the user doesn’t care about any of them individually. Splitting a story into tasks is useful planning, and it doesn’t turn the tasks into smaller stories.

When developers have to guess

One of the more expensive problems in software development is discovering requirements after implementation has started. A developer picks up a story, makes reasonable assumptions and starts coding. A few days later the feature is demonstrated. The product manager says it isn’t what they expected, the designer says the interaction is wrong, and QA finds important conditions that were never written down. Sometimes fixing that takes a few lines of code. Sometimes it means redesigning the workflow, changing the data model or rewriting a large part of the feature.

I’ve seen developers do exactly what the ticket described and still deliver something the business didn’t want. Blaming the person who wrote the story or the developer who built it doesn’t help. The team didn’t share an understanding before the work began, and that’s the problem worth fixing. It ends up as the kind of engineering work nobody needed.

We can’t anticipate every question before development starts. Requirements evolve, and sometimes we only learn what we need after we see something working. That kind of learning is healthy. Repeatedly discovering basic requirements that should have come up in a five-minute conversation is a different thing, and it’s avoidable.

Acceptance criteria for everyone

Written well, acceptance criteria are one of the most useful parts of a story. They should help the developer understand the expected behavior, the product manager confirm the business need, and QA decide whether the feature works. They don’t need implementation detail, and they should answer the important questions. For the profile example, instead of “Users can update their profile,” we might agree that:

• Users can update their display name and phone number.
• Email addresses can’t be changed through this workflow.
• Required fields are validated before saving.
• Users see a confirmation when their changes are saved.
• If saving fails, the user sees an error and their unsaved input is kept.
• Users can only change their own profile.

Now product, design, engineering and QA have something concrete to discuss. A developer may still have questions, and that’s fine. I’m not trying to eliminate every question. I want to reduce the assumptions nobody needed to make and surface the important decisions while they’re still cheap to change.

Story mapping shows the journey

Sometimes the individual story is fine, and the difficulty is that nobody has explained how the stories fit together. That’s where I find story mapping valuable. Take an onboarding process again. Instead of starting from a pile of tickets, we first walk through what the user is trying to do: create an account, provide information, complete the required steps, review the submission and get a confirmation. With that journey in front of us, we can see which capabilities each stage needs, and decide what belongs in the first release and what can wait.

The map keeps the context when the work gets divided. A developer working on one story can see how it fits the workflow, QA can see how the pieces connect, designers can spot missing interactions, and product managers can prioritize by user value instead of treating every ticket as equally important. Story mapping doesn’t replace good stories. It makes them easier to write, because the team understands the journey before cutting it into pieces.

A story should support a conversation

I’ve become more and more convinced that a user story should support a conversation, not replace one. A ticket shouldn’t work like a contract where one person writes requirements and another implements them without asking anything. Software involves too many decisions and dependencies for that to work consistently. A short conversation between product, design, engineering and QA can save days of work if it settles a few things: what the user is actually trying to accomplish, the simplest way to deliver that, what we’re deliberately not building, what happens when something goes wrong, and how we’ll know it works.

That doesn’t need to be a long meeting. A few comments on the ticket or a quick call is often enough. What matters is resolving the uncertainty before it turns into rework. Developers should also feel comfortable challenging a story, usually because they can see a simpler solution or a constraint nobody else has considered. The same goes for QA and designers.

Simplicity helps here too. I regularly push back on unnecessary complexity, in architecture, in process and in UX, for reasons I went into in what engineering leadership actually does. Workflows grow because we design for every future requirement, abstractions appear because someone anticipates change, and requirements expand because nobody wants to leave out something useful. Every extra step, condition and dependency is more to build, more for QA to test and more for users to learn. A simpler workflow is also easier to describe in a story, which is a good sign it’s easier to build and use. It lets us deliver something earlier and improve it from real usage, which matters most when time and people are limited.

Who owns the story?

Writing a good story shouldn’t fall on one person. Someone needs to own the business outcome and the priority, and in most teams that’s the product manager or product owner. Owning it doesn’t mean knowing every technical detail or predicting every edge case. Engineering brings constraints, dependencies and chances to simplify. Design explains how people will interact with the feature. QA finds ambiguous behavior and missing scenarios. The owner’s job is to bring those perspectives together and make sure every open question has someone responsible for answering it.

That doesn’t mean every story needs a meeting with the whole team, which would create a different problem. It means involving the right people when their knowledge is needed. I’ve seen teams spend more time maintaining their process than delivering software, and I don’t want story writing to become another administrative burden. The process should make delivery easier. I wrote more about that balance in when process helps.

What I check before development starts

I don’t think there’s a perfect template. A simple feature might need a few sentences and clear acceptance criteria. A complicated workflow might need a story map, design references, business rules and a few discussions before anyone writes code. Forcing every feature into the same format doesn’t make sense to me. What matters is whether the people delivering it understand the problem and agree on the outcome. Before a story moves into development, I want to know:

1. Do we understand the problem we’re solving and who we’re solving it for?
2. Do we understand how this feature fits the larger user journey?
3. Is the story small enough to implement, review and test without losing its purpose?
4. Are the important business rules and expected behaviors clear?
5. Have we named the assumptions that could cause significant rework?
6. Can product, engineering, design and QA each explain what success looks like?

If we can’t answer those, I’d rather spend a little more time on the story than find the problems after implementation. I also don’t want a team spending days documenting every scenario for a simple feature. Finding that balance takes judgment, and it’s something I’m still getting better at.

Short answers