This is the title of a user story:


Lately I read a lot of entries like this in our tool of choice. Here is a write-down of the description. Obviously I had to remove a couple details, but I hope it is still understandable.

A new SOAP element XXX must be defined in APPLICATION. APPLICATION will send XXX to OTHER_APPLICATION.


  • some information
  • more information
  • another piece of data

The received information shall be stored.

The information shall be retrieved, when

  • condition A (result of a user interaction with APPLICATION)
  • condition B (result of system event on OTHER_APPLICATION)
  • condition C (user interaction with APPLICATION)

APPLICATION is a web app for technicians/customer service. OTHER_APPLICATION is a hardware appliance deployed remotely without direct access to the user.

To me this doesn't feel like a (good) user story. Here are my thoughts about it:

  • ✅ Description is concise and tries to avoid hard implementation details like SOAP XML definitions or database table definitions.
  • ✅ The list of conditions can be used to demo and prepare test scenarios.
  • ❎ There is no information why this change to the SOAP API is needed - this should be the actual title or first sentence IMHO, something like "As technician/customer service, I need a way to get information about the state of OTHER_APPLICATION in case of a service failure." There can then be a note about the existing webservice used to communicate with OTHER_APPLICATION from the PO, just in case all developers have suddenly forgotten about it... 😕
  • ❎ There is a follow-up story to actually display the information to the user - it should be included in this story, because storing it in the database has no value to technicians/customer service. I understand that the asynchronous nature of the communication with OTHER_APPLICATION is the reason to split the story, but that is an implementation detail and the user story should be about a piece of functionality/a workflow which has value to the user.

Can anyone give me some pointers how to rewrite this story? Or am I wrong with my point of view? Do you see a lot of those stories in your projects and how do you handle them (as a developer/product owner/other roles)?

2 Answers 2


Is this a good user story? : No

This is a good technical description for the development team but not a User_story that should use "... sentences in the everyday or business language of the end user or user of a system ..."

The enduser "technicians/customer service" that for example repairs washing machines

  • needs infos when/where replacement articales are available at what prices.
  • doesnt care about technical implementation details like soap/database.
  • I like "...sentences in the everyday or business language...". I need to put this on my inner checklist when I go through entries in our system. Thanks!
    – cringe
    Commented Jan 11, 2017 at 15:27

I've worked on many projects where too much latitude was given on what could be considered a user story. This happened routinely when people just wanted to get things on the product backlog, regardless what it entailed, so we ended up with numerous items that were not from a user perspective, but from the perspective of a use case actor, or even worse, with no perspective whatsoever.

When I have a say on projects in this matter, I make it very clear: Don't confuse requirements with use cases with user stories. I was so irritated by this on a project a few years ago that I was compelled to put an article on LinkedIn about it.

What's a requirement, what's a use case, what's a user story?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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