Writing Agile User Stories With User Flows

What are User Flows?

User stories are a crucial part of the agile software development process. They help define the value a product feature brings to users and why users desire a particular feature. However, to truly understand the user's perspective and the value they receive, we need to introduce User Flows into the mix.

User Flows can be described as a user-centric tool that helps shift the focus of product managers and development teams from describing software features to discussing the value users derive from them. (GatherContent.com, Dec. 2021) In UX Design, User Flows are visual or written representations of the various paths a user can take when interacting with an app or web page. From the user's point of view, they illustrate the workflow or process, showcasing tasks visually through blocks connected by arrows, like a story flow chart. These diagrams don’t need to follow a linear path; they can encompass multiple pathways, loops, and other elements.

User Flows come in a variety of shapes and sizes but the two most popular are Task flow and Wire Flow/UI Flow:

Task Flow

• A Task Flow focuses on a single user task, omitting the entire solution flow

Wire Flow/UI Flow

• Wireflows combine wireframes and User Flows, using wireframes instead of raw blocks to visualize how an application will interact. High-fidelity mockups accompany Wire Flows, known as UI flows (uxmisfit.com, 2020)

But, for the purposes of story-writing, a set of bullet points in chronological order seems to be effective in documenting the sequence of steps a story should take from the beginning to the objective of the story.
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

While some user stories may not require a flow outline, most benefit from it, especially when tasks follow a particular sequence. Such sequences are not only helpful for the development team but also for future users. When crafting stories based on a User Flow, ensure that each step is clear, written in the first person, and outlines the user's path toward achieving their goal. Each bullet point or set of bullet points in a list can be expanded into a user story, defining the criteria for a story to be considered complete.

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

• Twenty Ways to Split Stories
• How You’ll Probably Learn to Split Features
• Patterns for Splitting User Stories
• InfoQ: How to Split User Stories
• Splitting User Stories: the Hamburger Method

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 a low priority. The user stories and their associated acceptance criteria 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, and 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 guide the conversation and implementation so the team won't forget about specific details or rules that need to be considered. The acceptance criteria help 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's restrictions.

The SilverLogic: Transforming Ideas Into Reality

For over a decade, The SilverLogic has been an agile software development company that harnesses well-crafted user stories and User Flows to transform ideas into features and software for our clients. Our meticulously crafted user stories save time and money, boost productivity, and reduce development costs. We collaborate closely with clients throughout the entire process to deliver the user experience that their business deserves. Contact us today for help with your big idea!