If you’re on a software development team, user stories are a useful tool in understanding how a feature works from the perspective of your users. A user story is a simple description of a feature. It can help developers understand types of users, what users want to achieve through a particular feature, and why.
Typically, all team members will gather at the beginning of a project and participate in a story writing workshop. These workshops work best when both the business and development team collaborate closely to clarify details as code gets developed.
Here are five tips for writing strong user stories.
Develop personas
Personas are hypothetical representations of potential users. They help capture who your users are in greater detail. Personas can include a variety of elements, such as a name, personality traits, how they benefit from using the product, and other relevant characteristics.
Since there are usually multiple types of users who will interact with your product, developing a persona for each one helps to scope out the range of potential users.
Keep stories short and sweet
User stories are meant to express the smallest unit of a product feature. Therefore, stories should be clear, concise, and easy to understand. For all user stories, be sure to include a persona, what they want to accomplish, and why. For example:
As [Olivia the Office Manager], I want [a section on the company site to display upcoming office events] so that [I can promote them to the staff].
In addition to the template above, teams may find it useful to write user stories on index cards. The physical constraints of an index card may help team members fit the entire user story on just one side of the card. Index cards also encourage collaboration, and teams can group the cards together on a board or a wall to visualize requirements.
Start with epics
Epics are large, overarching stories that eventually get broken down into smaller, more granular stories. For example:
As HR Manager Amy, I want a virtual job board.
The example above provides a general outline of the proposed feature but does not describe who Amy is specifically, or what she hopes to achieve through the use of the feature.
Creating epics first will help teams develop a better understanding of the functionality without committing to specific details. You can also relate feedback to the appropriate epic more easily than you can if you have many detailed stories in your product backlog.
Refine stories
Once you learn more about the “what” and the “why,” you can start breaking epics down into more detailed stories. When these stories are ready, they will be clear, realistic, and testable. For example:
As [persona], I want [what?] so that [why?]
So a real example may look something like this:
As HR Manager Amy, I want a virtual job board so that I can view a candidate’s status and manage their application throughout the hiring process.
At this point in the process, all team members should have a shared understanding of the story and should work together to determine if the story is finished.
Test user stories with acceptance criteria
The acceptance criteria allows you to make a story testable and ensure that it can be released for demo to users and other stakeholders. Just as you can use a template to write user stories, you can also use a template for acceptance criteria. For example:
Scenario: Title
Given [context]
And [more context]
When [event]
Then [outcome]
And [another outcome]
In the case of Amy the HR manager, the acceptance criteria may look something like this.
Scenario: Unviewed Job Submissions
Given the fact that there are several unviewed job submissions
And candidates have not been updated on the status of their application
When Amy the HR manager logs into the virtual job board
Then she can update candidates of their status
And manage their applications throughout the recruitment process.
User stories are a great way to bring development teams together in a collaborative manner. They are an essential part of product development and help center focus on the most important customer requirements. By following these guidelines, you’ll create a better, more user-centric product.