Writing Agile User Stories With User Flows

As a popular component of the agile software development cycle, user stories help to articulate what value a product feature can bring to users and to understand why the users they want a particular feature.
User flows are a user-centric tool helps the product manager and development team shift their focus from writing about the features of the software to discussing the value the users will receive them. (GatherContent.com, Dec. 2021)
As user stories primarily serve to guide developers during implementation and to communicate with stakeholders what developers are doing,, it is important to describe both the value the work will bring to the user and the “hard” acceptance criteria associated with the story. Software development agencies in particular must pay attention to both aspects as the agency-client relationship may sometimes drift a bit more in the “contract negotiation” direction than the “customer collaboration” direction.

Using a User Flow to Draft User Stories

Some user stories may be written without a flow outline. For example, when actions are very simple don’t have to be performed in a specific order. However, most things follow some sort of sequence, and a suggested sequence might be helpful for both the development team and future users.

Preparing stories based on a user flow, make sure each step is clear, in the first person, and in an order that clearly delineates the steps the user should take towards attaining their goal.

In the example below, eEach bullet point or set of bullet points in a list can be fleshed out translated into a user story and can also be used to specify what is expected for a story to be considered done. Tak


Let’s prepare the first story by rolling the first two steps of the flow into one user story:


Here, we rolled two steps in the flow into one story.

Step 3 seems like a candidate for this user story:


What if a User Story is Too Large?

I enter shipping and payment information before confirming order

Perhaps after a team meeting, the team determines this step in the user flow is quite complex in practice, and would be better served by being split into multiple stories. A simple heuristic is to split wherever you read an “and”. 

In this case the user story mentions shipping and payment information; these items could be split and would look something like this:


There are many strategies a team can use to split stories, and some stories may have to be split or reworked multiple times before they are accepted by the client and development team.

Story Splitting: Further Reading

Carefully Written User Stories Save Time

Carefully written user stories can save you time. They can be reprioritized, added between other user stories, and can remain in the backlog if they remain low priority. The user stories and their associated acceptance criteria They are always there to be discussed, refined and worked on at a later date.

Additionally, a review of finished work can be used to adjust the scope of the feature user stories through progressive refinement. For instance, the credit card info may end up being inconvenient for your customers given how your app and business work, you may decide that you want to use PayPal instead of taking Credit Cards directly.

Reviewing Acceptance Criteria

While user stories help focus the software development team on the value to the user, the acceptance criteria guides the conversation and implementation so the team don’t forget about specific details or rules that need to be considered. The acceptance criteria helps the team define scenarios and how the final product will behave so the team doesn’t have to go back and redo some pieces because they don’t align with the business or the environment restrictions.

Leave a Comment