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