Hello all, please excuse any formatting issues (and the length) as this is my first post.
I have an interesting situation that I'm wrestling with - technical requirements as user stories. I've read the other threads here that are similar to this, but none of them seem to provide a clear solution, so I wanted to open a new thread so I could tailor it to specific needs.
Here is the high level:
We are a data vendor, meaning that the client is not in house, nor is the system that returns the data itself in all cases. The client in this case may be a loan officer, using their loan system to get a quote on buying a new house, for example. Their system would call ours to build a file, and then our system is calling a third to get the data through the API using XML requests. The recipient system API is being updated, so therefore we have to update our requests as well. The XML adjustments on our side consist of addition of some XML attributes, while removing others.
From what I gather from reading the other posts, I should still be guiding the team to write the stories as USER stories, which in this case doesn't make a whole lot of sense, since the user really doesn't see any of the updates. From the user perspective, the story would basically be: "As a loan officer, I want to be able to request accurate loan data from company X, so that my quote to the customer is accurate". However, this doesn't take into account any of the changes that must be made to the XML itself to make that request successful. (After all, this user story would be exactly the same before the changes were made as well as after....). The user also cannot see what happens on the backend or in the XML, but there is no UI they can use to view these changes.
SO....
The question is this:
When I have technical aspects that form the basis of the change, how should these best be written so that we:
a. Cover the User Aspect without seeing the changes in the UI, and
b. Cover the Technical Aspect without telling the developers HOW to do their job, while
c. Keeping the PO from writing a million stories?
My thought was to do something like the following:
______________________________________________________________
Story #1:
"As a consumer of data through the API, I want to be able to send an XML request using the new XML schema to company X so that the data is returned in it's new format and is correct."
Acceptance Criteria 1:
Given that I send an XML request
When that request is sent to the new API location
And the request contains the following (new) information (outlined in NEW XML structure below)
Then the response should be received from company X that has accurate quote information
NEW XML:
Attribute 1 - Value 1
Attirbute 2 - Value 2
Attribute 3 - Value 3
Attribute 4 - Value 4
Attribute 5 - Value 5
Attribute 6 - Value 6
Attribute 7 - Value 7
Attribute 8 - Value 8
Attribute 9 - Value 9
All values should be reflected with values in response XML.
Story #2:
"As a consumer of data through the API, I want to be able to send an XML request using the OLD XML schema to company X so that the data is returned in it's original format and is correct."
Acceptance Criteria 1:
Given that I send an XML request
When that request is sent to the old API location
And the request contains the following (old) information (outlined in OLD XML structure below)
Then the response should be received from company X that has accurate quote information
OLD XML:
Attribute 1 - Value 1
Attirbute 2 - Value 2
Attribute 3 - Value 3
Attribute 4 - Value 4
Attribute 5 - Value 5
All values should be reflected with values in response XML.
______________________________________________________________
1.) The developers would break down these stories into tasks or subtasks that would allow them to configure the attributes for the new structure during grooming or sprint planning - obviously there are some attributes that would need to be added from the old (existing) structure.
2.) The stories written in this way would also allow QA to perform testing to ensure that the system would remain backwards compatible.
3.) The stories written in this way still follow the INVEST model as well.
The only real downfall that I see is that we get awfully close to telling the developers how to do their jobs....which is a major no-no.
The only other way I can think of to write this is one story per attribute, but that doesn't really help out the developers....who are making a single solution, not a solution per attribute.
I'd love to hear what you guys think, get a few different points of view....because this one has me stumped!
Thanks,
-KCP