Suppose we have a process like the following:
- Super user receives an internal request to initiate a process.
- Super user approves the request.
- An external process belonging to a third-party is triggered.
- 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?