I have a question regarding user stories and with agile in general. I read a few articles about user stories and there is a thing, that is not clear to me. For example in this article there is the following sentence:

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail.

However quite often a features cannot be implemented without details.

Let me give a few example.


An external service should be used in the current backend. The backend should call several endpoints of the external service.

There are important things like what endpoints should be called, what should be the content of the request, in what order endpoints should be called. So these are really technical details I admit and most probably communication/research needed to get the information regarding the external service. Who is responsible for that?


A new page added to the application. Here are also details that are important like the caption of the button, color codes, messages to the user (inforamtion,warning,error).

Who should define it, the story writer or the developer? Should this be part of the user story?

I also read a statement about user stories like,

"User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality."

I am really not against communication, but at the end of the day the outcome should be written somewhere in my opinion, because spoken communication is not permanent and the information can be lost.

So to summarize it, based on what I read, user stories are about what should be implemented and not about how. I think how is also important, because things can be done in good and bad way and the later it turns out, that something is bad, the more expensive is to correct it, but I couldn't find that how the information should be shared.

4 Answers 4


I want a glass of milk.

What kind of milk?

Don't care. Just milk.

Warm or cold?

Whatever give me milk.

2% or ...


OK fine here's your milk.

Eew, give me some milk that isn't past it's sell by date.

User stories are a few sentences in simple language that outline the desired outcome. They deliberately do not go into detail because that's design. Don't ask user stories to be design. Many designs could fulfill a user story. A user story is about a needed experience. Not a solution.

Don't be surprised if user stories change over time as users feel the experience. Don't waste a lot of time trying to avoid gaining this experience. Well, as long as it won't kill anyone.

[Implementation details] who should define it, the story writer or the developer?

The developer handles the details. Implementation details do not belong in user stories, requirements, or tests. They belong in the code.

  • 2
    This really hits the idea of user stories beautifully!
    – Daniel
    Commented Nov 25, 2019 at 22:15
  • 1
    @Steve malevolence not required. Coders communicate best with code. Users communicate best by using. Commented Nov 26, 2019 at 2:57
  • 2
    @Steve, ""Coders communicate best with code. Users communicate best by using." - what does that even mean haha?" It means that the user often doesn't know what they want. So the developer creates a design (the code), gives it to the compiler to build into an app then gives the app to the user to use. The user then feedbacks on whether that is what they wanted or not. This is the essence of short iterative development cycles (aka loosely speaking, agile) and is proven to be the most effective way to meet a user's needs.
    – David Arno
    Commented Nov 26, 2019 at 13:41
  • 2
    @DavidArno exactly right. So long as you don't kill anyone. Commented Nov 26, 2019 at 14:40
  • 2
    @steve you are not your user. Don't pretend you are. When it comes to your code you are the worst one to peer review, proof read, test, or use. Get someone else. Watch what you're putting them through. Look up hallway testing for a good lesson on this. Commented Nov 26, 2019 at 15:44

Users and other stakeholders should not have to be concerned about how you implement your system. All they should care about is what it does, not how it does it.

You're quite correct that many features and user stories require additional details to be implemented properly. But, from the stakeholder's perspective, those details always embody behavior, not implementation.

It's up to the stakeholder to provide enough details about the behavior of the system so that you can work out an appropriate implementation. It's up to you to come up with an implementation that satisfies the stakeholders' expectations for behavior.

The stakeholder is neither qualified nor interested in providing technical details about how you intend to put your system together. If your stakeholder says something like "I think you should write this in Java," or "I think you should use micro-services," you should be the first person to say, "let me worry about the technical details. That's why you hired me."

To find out whether or not you actually need to use (for example) microservices, ask your stakeholders questions about non-functional requirements.

  • How many users will be using the software (not "what architecture should we use")?
  • What is the expected response time of the system (not "What language, framework & database should I use")?
  • What sort of computations will be required (not "will I need an OLAP cube")?
  • How much data will be stored (not "how many disks will I need")?

These are all questions that can be answered from a business perspective, not a technical one.

If your question is merely "where do I write these details down," the answer is "in the same place you wrote down the user story."

  • I was hoping, that the examples I wrote will be used in the answers too. I accept, that the stakeholder doesn't have the necessary technical knowledge. But it's not guaranteed, that the developer has it. So imagine, that in the back-end example some developer picks up the story to integrate with the external service. When you do such things you cannot just randomly call endpoint with random request body. This information should be gathered somehow. In my front-end example, what I wrote is really not technical. What about those information? Commented Nov 26, 2019 at 7:08
  • 1
    @user1162316, The developer(s) picking up the story are responsible to get it into a working state, even if that includes figuring out how to interact with an external service. If somebody has advance knowledge about that, they could could add that to the story as "useful information" but it would not be part of the story per-se. The front-end example could be part of the acceptance criteria of the story (which are part of the story proper). Commented Nov 26, 2019 at 11:43

An easy answer is to let the "self-organizing" team determine how many details it needs. As part of the Sprint Planning (or separate all-team Grooming Session), the team discusses the story with the PO and has the final call on whether the story is ready to go into the sprint. To repeat a theme from the other commenters, this discussion focuses on the "what," not the "how," which is left to the members who work the story. That said, a little of the how might be discussed to ensure the what is feasible or provide architectural direction. When facilitating, I will gently warn against too much "solutioning," however.

Based on the large body of research literature about teamwork in general, I suggest recording all agreements from the discussion as a brief bullet list on the story card (whether paper or digital), so people don't waste time later trying to recall what was decided! This also prevents time wasted due to misunderstandings, by asking everyone to sign off on the language on the card--user story, acceptance criteria, and list of agreements--before moving on.


Why does there have to be a backend service hitting multiple endpoints? Who decided that? Why does there have to be a new page on the website, instead of a route/experience/div, whatever? That's the problem, your story is specifying everything without consulting the dev team. How the information gets to and from where to the web app is not your concern as product owner (product manager, or whatever we call them)- however the REALITY is, if you don't put that in the story, your teams may not know what to do. The argument there is "then you have the wrong folks" but is that true? Is a developer or QA person supposed to understand/know how the company handles support issues for customers, outages, redundancy, and how things are monitored, alerted on, administrated? Impossible. So this agile teams say "well we don't know who handles databases... they are oracle. that means licenses. lets just use a free open source db" -- and then support team is like what's this. We can't support it. And then the team supports it. And then there's no insight into its health from IT to upper mgmt and so on and so on. Its great to not be waterfall... However, sure seems like everything AFTER deployment to production is waterfall.

Not the answer you're looking for? Browse other questions tagged or ask your own question.