How can I specify user stories for processes with third-party involvement?

Question

Suppose we have a process like the following:

1. Super user receives an internal request to initiate a process.
2. Super user approves the request.
3. An external process belonging to a third-party is triggered.
4. Once third-party process is complete, super user receives the result and either accepts or rejects it.

It is easy to see how to formulate user stories for 1, 2 and 4 but 3 is a bit trickier. Do I:

• Skip it because it is external to our system and treat 3 as an implementation detail of 4 (after all, 4 is dependent on 3 happening); this may require external documentation of the actual process or potentially bloated user stories/tasks for 4.
• Treat the external system or one of its users as a user and write the user story from their perspective ("as a [system x] user, I want to process..."); this seems like it should be out of the scope of our functional requirements.
• Treat it as a "task" against 2; this doesn't seem quite right as the functionality of approving something doesn't really imply the triggering of some other process.
• Something else entirely.

It seems that the act of the user approving the request and approving the response should be seen (functionally) as independent of the fact that the process happened in the middle but - without specifying that somewhere - 4 could conceivably be "implemented" even though it will never actually happen (i.e. if the response is available, the user sees it but a response will never actually be available because the third-party process is never actually triggered).

Is there a prescribed or conventional way for dealing with these types of scenarios?

Answer 1

I find it helpful in these situations to step back from the 'functional requirements' for a second and try to view it as the higher level business process that is occurring. For me, it seems to me like you only have 3 stories:

Primary Stories

1. As a Process Initiator, I need to be able to submit an internal request to the Super User for approval.
2. As a Super User, I need to be able to approve requests in order to ensure only qualified requests are sent to the external system.
3. As a Super User, I need to be able to accept or reject the results of the external system processing.

The fact that data is being transferred in some way between systems is an implementation issue and, in my opinion, should not be part of the acceptance criteria. If the Super User can approve the request and a pigeon flies it over to some folks in Elbonia for further processing, that is just as valid as long as the data gets to the external system and a result comes back in some way for accept/reject.

However, my pigeon analogy may have triggered a "but that would take too long" which indicates you likely have an acceptance criteria on the story regarding the acceptable transaction times for sending and receiving requests.

From an implementation perspective, this allows you to deliver stories against a stubbed API and complete stories, keeping them independent of each other.

External System Stories

If you were also developing the external system, I would suggest an additional story for the external development team:

1. As a Super User, I need approved requests to be processed and have a value returned for acceptance.

You would then have the acceptance criteria over how to process and return values in that story for the team developing the external system.

Other Hidden Acceptance Criteria

The above stories seem to have an incomplete picture. If the data is never actually processed and stored, you wouldn't be able to go back and see it later. Does that matter? If you built up an API stub and didn't do the external system, why would that be bad?

(It would be bad, but the question should trigger a thought about other stories you probably need)

Answer 2

One could also argue that the case described above is a single user story if the business value to the super user is not derived until step 4 in the process is complete.

Consider a higher level user story such as:

AS A super user I WANT TO perform XYZ business process SO THAT I can accept/reject the results.

1,2,4 then become Acceptance Criteria to validate that the Super user can do these steps in the system...validate the super users receives request, validate super user can approve/deny the request, validate the super user can, reject/approve the result.

3 could also be considered an acceptance criteria...something like: "Validate the internal system consumes the output from the external system"

If the high level user story is not granular enough to fit within an an iteration, Jay S' answer provides a great breakdown.

Answer 3

As the third-party process is not a part of the system you are developing, but your system needs to interact with it, the third-party process is an actor for your system.
Generally, an actor can be regarded as a generalization of a user. Actors can be human users, but also external computer systems that your system communicates with.

You could write the user story for step 3 with the external system as the user:

3. As <external system>, I want to receive a notification in <this way> when a request is approved, so I can perform <external process>. I will indicate completion of <external process> in <this way>.