How to breakdown a business process workflow into user stories
The Product owners have specific requirements around how the Product should enable the users in a complex business process workflow (approvals and what not). The easiest way to document the requirement is in the form of a process diagram/flowchart.
In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?
Option 1 Have generic user stories that encompass the workflow, and attach the flowchart diagram as a supporting document. e.g. As an author, I want to be able to submit my article for approval process so that it will get published.
Pros it's easier for people to understand and digest - rather than reading 10-20 user stories.
Cons it becomes an epic
Option 2 Break down the complex flowchart into its own user stories. e.g. As an author, I want to be able to submit my article. As an editor, I would like to get notified when an article has been submitted so that I can review it. As an editor, I need to approve an article As an editor, I would like to be able to request for more information ...
Pros pure Scrum. easy to prioritize/estimate/plan
Cons As you can see even a short business process workflow will easily explode into a lot of user stories.
Answer
If this business workflow is like most business workflows, each of those steps will have a significant number of rules. Those rules should map into acceptance criteria for those stories and ideally, automated tests to prove that the code works as intended. Because of the potential for a lot of acceptance criteria, I would lean towards the second option.