How to breakdown a business process workflow into user stories

Question

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 1

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...

• Track items on a burndown chart
• Deliver fully functional work (not an unusable subset of work)
• Have estimatable portions

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.

Answer 2

We're currently building a business process based content management system. We split our processes into stories as per your 2nd option.

But, of course, we keep the flow diagram handy. In fact, we print it out and stick it to the wall. We even keep every old version of it so we've our own paper based version control stuck to our wall (in addition to using git for the electronic version ;-) )

Answer 3

For me all agile is about using common sense. I this case you have perfect desing so just implement one and don't look for unecessary things.

Answer 4

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.

Answer 5

I tend to go towards Features/Epics early on with the core end user/stakeholder value-adding functionality, such as in your example to "Publish an article so that the subscribers can get the latest news". Then once the Feature is getting closer to implementation I'll split it into implementation sized stories if needed.

Most non-trivial business workflows benefit from being split up during implementation so that they can be continiously deployed and verified in order to get early feedback from the stakeholders. The big con of having everything as one big bang implementation is late validation. I think that having early feedback is outweighing the increased administrative burden of handling multiple stories.

A tip on how to split epics into stories: Lasse Koskela has a great writeup on how to split stories in different ways.

Answer 6

In Scrum however, it is advised for requirements to be in the form of user stories. What is the best way to approach this?

The two options that you have mentioned are not really options, they are sequential stages, IMHO. During Agile Requirements Gathering or Product Planning the first step is to create EPIC stories. After you have those Epics, you need to break them down into smaller chunks.

Without the EPICs you will most likely to run into the issue of creating random stories without getting a grasp on the sense of belonging of a story. You can in a way create a hierarchy in User Stories. Without understanding that, everything is just random, hence it makes it tougher to wrap your head around or manage the stories as a PO.

Offcourse there is much more to all this than what I mentioned in the above paragraph. That's why probably you need an experienced Scrum Coach or do a lot of diligent reading/implementing on Agile Planning and User Story writing.

Hope this makes sense. I would suggest reading Agile Estimating and Planning by Mike Cohn for anyone who even remotely thinks of taking up a PO role. Best of Luck!

Answer 7

Workflows are an interesting entry to writing user stories and epics, but user stories don't map to work flows, they map to business capabilities. So you are incorporating some fallacious thinking from the start in this question. Workflows are a good tool for the conversation, but will live independently of workflow as they are about functionality, not timing. Timing lives in the business rules. On that note, business rules are not Acceptance Criteria, they are the connection between Acceptance Criteria, which are features that can be demonstrated by a product owner, and Test Cases. Again, Acceptance Criteria are about features, not behavior. Behavior lives in the business rules. For instance I might have User Story for an ATM that says "As a user, I can check my account balance." And the Acceptance Criteria could be "If I am overdrafted, I get an alert notice." The rules for what constitutes an over draft (I had $1000 in my account and deposited my $2500 pay check, but that won't clear before my $1500 mortgage payment, etc.) are not acceptance criteria. They are business rules whose execution results in the demonstrable action of the Acceptance Criteria. Note, that this user story could be captured through a workflow analysis, but might live in many workflows (or none).