User Stories for Scrum Integration

Question

I am working on a project that has very complex integration needs, in particular with receiving and sending EDI data and all the “fun” things that happen between them. I can definitely focus on data processing (validation, required fields, transformation), but the problem I am facing is how to create backlog stories and epics to plan and track work.

It is very easy to say: "As a manager, I can refuse a vacation request so that I can make sure that I have enough staff to fulfill my obligations." In fact, I am very good at this, but I am very new to such integration efforts.

For a large integration project, it’s tighter to indicate who the user is and what the meaning is. EDI integration is just interface (non-functional) requirements, but implementation is a big effort.

Can someone give some recommendations on how to structure / frame these requirements in the release of the product that I am creating?

Answer 1

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

But you must be careful not to be obsessed with this pattern. It is only a tool of thinking. Trying to set a restriction in this template is a good exercise, as it helps to make sure that you understand who wants what and why. If you end up with vague wording, drop the pattern. If you cannot find a way to formulate a restriction, simply write the restriction in any way natural

Answer 2

Scrum does not indicate that requirements should be written as user stories, and you should use what ever best suits you. If you're fighting stories like "AS A," try "ORDER AS I WANT." If this is not used, use case use models.

Recommendations are not contracts, but placeholders for communication. The key here is to have enough information for planning purposes, which gives the team a sense of knowledge of what needs to be done. Details can be discussed in the sprint.

Answer 3

What I do in such situations:

1) Try and try the simplest bit of end-to-end functions that we can implement for integration.

2) Try using a use case for this integral

3) Translate this into stories (optional step: Stories are not the law of physics. You use them if they are useful.)

For instance:

1) Good - authentication seems to be the most trivial thing to implement, which affects everything.

2) Hey - authentication in itself is useful. We can use it to find out if this group of users can access the data.

3) "As a site administrator, I want to make sure that only authorized employees have access to Foo to prevent access to important information."

Thus, you will always have a working EDI system - it just covers part of the functionality. The subset that you can grow over time - I hope, in order of importance of functionality for your business.

My real preference, however, would be to go a little deeper into why EDI is performed. This is usually not because "EDI" is the function that people want. This is because EDI is required for some other functions in the system.

In this case, instead of having a separate EDI project, I would rather use all that is needed - EDI to stimulate the development of the EDI level. The stories in (3) above will then be from a live project - and you will be much more inclined to build what you need and avoid waste.