3

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.

7

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.

20
  • 2
    This really hits the idea of user stories beautifully! – Daniel Nov 25 '19 at 22:15
  • 1
    @Steve malevolence not required. Coders communicate best with code. Users communicate best by using. – candied_orange Nov 26 '19 at 2:57
  • 1
    As I said, the developer. The developer creates the design and the code. They strive for a design and implementation that fulfills the user stories. – candied_orange Nov 26 '19 at 7:36
  • 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 Nov 26 '19 at 13:41
  • 2
    @DavidArno exactly right. So long as you don't kill anyone. – candied_orange Nov 26 '19 at 14:40
6

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

2
  • 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? – user1162316 Nov 26 '19 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). – Bart van Ingen Schenau Nov 26 '19 at 11:43
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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