Technical Requirements as stories - need help

37 views
Skip to first unread message

Kc Para

unread,
Feb 18, 2015, 3:39:29 PM2/18/15
to scruma...@googlegroups.com
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




Kurt Häusler

unread,
Feb 18, 2015, 3:58:47 PM2/18/15
to scruma...@googlegroups.com
Don't worry too much about sticking to the user story format. Scrum only talks about Product Backlog Items, of which user stories are one popular form. I actually like your suggestions. They map nicely to the use of e.g. a ATDD tool etc. I don't think it is telling the developers how to do their jobs much more than more user oriented requirements. This differs a bit from the typical agile approach where one team will do a complete slice of functionality from the UI all the way down, but if you are implementing some backend system you can still do that just fine. It is actually not that different to e.g. a web app that generates html. Here you are generating xml instead. I think you are on the right track, and the only issue seems to be your concern about telling the developers how to do their jobs, which I don't think is a big issue in this case. You are focusing on externally visible aspects of the "features" which is fine.

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

Kc Para

unread,
Feb 18, 2015, 5:27:25 PM2/18/15
to scruma...@googlegroups.com
Thanks Kurt, that's very helpful.

I know we're focusing a lot on structure, as in the company we're not only trying to get the sprint done, but also to get the team functioning in a process that is uniform and repeatable...which sort of necessitates a structure to the stories and acceptance criteria.  I have great hope that one day we can take off the training wheels and simply use the stories as a basis for the conversation of what needs to be done during grooming (and just make the tasks on the spot if necessary), but for now, structure seems to carry an equal importance to communication and closing the PBIs on time.

Nice to know I'm not completely out of my mind either!  

Dan Rawsthorne

unread,
Feb 18, 2015, 5:34:07 PM2/18/15
to scruma...@googlegroups.com
Just use Stories, which provide value to somebody. Don't use the story format, just write down what is wanted... don't let process get in the way of getting work done.
Dan Rawsthorne, PhD, PMP, CST
3Back.com
1-855-32-3BACK x323
Author of:
    Exploring Scrum: the Fundamentals
    Exploring Scrum: Patterns that Make Scrum Work
--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.




This email is free from viruses and malware because avast! Antivirus protection is active.


Wouter Lagerweij

unread,
Feb 18, 2015, 5:35:02 PM2/18/15
to scruma...@googlegroups.com
Hi KC,

I think you're doing pretty well. As Kurt is saying, don't worry too much about telling the developers what to do. Most of this work is adopting to specific specifications for external interfaces and there's not any way to avoid that being somewhat constrictive... So what follows is just thoughts on different ways of looking at the stories, as you asked for.

My main comment on your stories would be that for me (an outsider, who doesn't really understand your domain...) it it not immediately clear what the functionality is that the stories are meant to ask for. Is the format the only thing that is specific for the new call? If different attributes are added to the call to the backend service, does that have any influence on its results? If it's just a total package, I could see a story saying that in order to get <whatever is better in the new service> as an api user I want to be able to retrieve results that rely on/are enhanced by (in a specific way?) additional data support end in new format X.

Not too different, but still focused a little more on the value delivered.
You could have separate stories if different sets of additional data provide different value.

If the relation between values given in the request and in the eventual reply is very direct, one could see your acceptance criteria a little more specific, such as:

Scenario outline:
Given a request that has <input-attribute> set to <input-value>
When that request is sent to the new endpoint 
Then the response will contain <output-attribute> set to <output-value>

Examples:
| input-attribute | input-value | output-attribute | output-value   |
| attribute-name1 | a-value     | attribute-name2  | a-similar-value| 
| attribute-name3 | b-value     | attribute-name4  | b-similar-value| 

This triggers some questions on what kind of transformation the attributes go through in the process. If the link is less direct, it might give reason to think about relations between input and output. Then again, if all those are very simple, this might be overkill:-) 

Wouter

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at http://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages