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.
I agree with pma_. Do what makes sense. In this case, you have some great looking user stories.
"As an editor, I would like to get notified when an article has been submitted so that I can review it."
If you have a ton of these, then perhaps they are too small. They would all be 1-2hrs. That's probably not a good thing to have. In that case, try grouping them. Perhaps "As an editor, I want to be able to manage articles". That would include several of the ones you have already.
Keep in mind the goals of user stories...
If you can achieve those goals, you're good. If not, try again.
Oh, and one last thing - keep the flow diagram, don't throw it out in favor of stories. But supplement the stories with it.