This is the title of a user story:
As APPLICATION I require a new SOAP element for OTHER_APPLICATION
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.
OTHER_APPLICATION shall return
- 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)?