Agile – How to Specify User Stories for Processes with Third-Party Involvement

agileuser-story

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?

Best Answer

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)

Related Topic