User stories for integration in Scrum [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I am working on a project that has very complex integration needs, specifically with receiving and sending EDI data and all the "fun" stuff that happens in between. I can definitely focus efforts around data processing (validation, required fields, transformation), but the problem I am having is how to frame stories and epics in the backlog to plan and track work.

It is very easy to say "As a manager, I can deny a vacation request so that I can make sure that I have enough workers on staff to meet my commitments." Actually, I am very very good at this, but I am very new to this kind of integration effort.

For a big integration project, it is tougher to indicate who the user is, and what the value is. The EDI integration are just interface (non-functional) requirements, but the implementation is a big effort.

Can anyone provide some guidance on how to structure / frame these kinds of requirements in the product backlog I am creating?

Answer 1

Mike Cohn has something to say about this, I think this last paragraph is very relevant

But, you should be careful not to get obsessed with that template. It’s a thinking tool only. Trying to put a constraint into this template is a good exercise as it helps make sure you understand who wants what and why. If you end up with a confusingly worded statement, drop the template. If you can’t find a way to word the constraint, just write the constraint in whatever way feels natural

Answer 2

Scrum does not specify that requirements should be written as user stories and you should use what ever technique best works for you. If you are battling with "AS A" type stories, try "IN ORDER TO AS A I WANT ". If that does not use, use use case modeling.

Requriments are not contracts, but placeholders for communication. The key here is to have just enough information for planning purposes giving the team a sense of knowing what has to be done. The details can be discussed in sprint.

Answer 3

What I do in situations like this is:

1) Try and come up with the simplest bit of end-to-end functionality that we can implement for the integration.

2) Try and come up with a use case for that integration

3) Translate that into stories (optional step: Stories aren't a law of physics. You use 'em if they're useful.)

For example:

1) Okay - looks like authentication is the most trivial thing to implement that touches everything.

2) Hey - authentication by itself is useful. We can use it to know whether this group of users can access the data.

3) "As a site administrator I want to make sure that only authorised stuff have access to Foo to prevent valuable information being publicly accessible"

This way you'll always have a working EDI system - it just cover a subset of the functionality. A subset you can grow over time - hopefully in order of the importance of the functionality to your business.

My real preference however would be to dig a bit further in to why the EDI is being done. Generally it won't be because "EDI" is a feature that people want. It'll be because the EDI is necessary for some other bit of functionality in the system.

In which case, rather than having a separate EDI project, I would much rather use whatever the thing-that-needs-EDI is to drive the development of the EDI layer. The stories in (3) above will then be coming from a live project - and you'll be much more likely to build what you need and avoid waste.