How to give/get the necessary implementation details in agile user stories?

Question

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.

Backend:

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?

Frontend:

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.

Answer 1

I want a glass of milk.

What kind of milk?

Don't care. Just milk.

Warm or cold?

Whatever give me milk.

2% or ...

Milk!

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.

Answer 2

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."

Answer 3

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.

Answer 4

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.