The Business Analyst’s Guide to Writing User Stories
A user story is the smallest unit of work in an agile framework. It’s not a feature, but an end goal that the user has when using the software. The user story will convey what the user wants to achieve and states it in a simple, non-technical way.
Why Should I Use Them?
After reading a user story, the team knows why they are building a feature and the value that the feature creates for the end user. Knowing the value of the feature helps create the best user experience possible, ensuring that the user can accomplish their goal with the application.
At FreshWorks, we find user stories beneficial because:
- They focus on the user and their needs. Stories keep the team focused on solving problems for real users, and ensuring that they are able to accomplish their goals. This purpose can often get lost if there’s a checklist of other to-dos.
- They allow for equal amounts of understanding and collaboration. When the client’s requirements are written in a way that can be understood by the developers, and the user’s end goals are described in layman’s terms for project managers, stakeholders, and clients, the team can work together more cohesively to deliver the best solution for the user.
- They drive creative solutions. User stories don’t explain how the user will achieve something, just what they can accomplish from doing it, which enables developers to implement solutions in whichever way best helps the application and the end user.
When Do I Use Them?
The FreshWorks Business Analysts that have your user stories covered during the discovery phase of your development project: Sienna, Zac, and Stephanie
User stories are written throughout the agile project, however, the Business Analyst assigned to the project should produce user stories in the discovery phase. After the discovery phase, everyone on the team will then participate to create a product backlog of user stories. This backlog will fully describe the functionality to be added over the course of the project. In an agile project, new stories can be written and added to the product backlog at any time, and by anyone.
How Can I Make One?
There are 4 steps to creating good user stories, which require the collaboration of the client and the business analyst on the project:
1. Validate the Needs of the Users
The client first must clearly define the users who will use the application. It is very important to know the user, their pain points, needs, and goals. You should typically have a solid understanding of your users, but no matter how well you think you know the user there is no substitution for performing market research and interviewing potentials users, prior to as well as during the discovery phase. Because this is so integral to the process at FreshWorks, we offer market research as a service and will often encourage our clients to collaborate with us for this. Our business analysts work with UX researchers to deliver focus groups, perform interviews, and compile other findings to create data-driven user experience maps and user personas.
2. Create Epics
Epics can be described as a major component of the application. They are generally drafted before user stories are written to map out the bigger components, but are also further defined as more user stories are identified. User stories are then grouped into these epics. Organizing user stories into epics is useful for planning what features developers will build and in what order and can give a high-level understanding of the features of the application.
An example would be creating a “login” epic, and having all user stories related to login under that epic, such as:
- As a user, I want to login, so I can access the application.
- As a user, I want to login with my Facebook account, so that I can login faster.
3. Writing User Stories
After the users and the epics have been defined, the business analyst on the project will begin drafting user stories. Epics can be added and removed as different components are identified. This step can also be done collaboratively with clients if they are interested in contributing.
User stories typically follow a simple template that captures the user, and the goal that the user has, in a simple and non-technical format.
As a < type of user/role >, I want < some goal > so that < some reason/benefit >.
We also use a handy acronym, INVEST, to remember the best-practices of writing good user stories. A good user story should be:
- Independent: Developers should be able to implement the user stories in any sequence
- Negotiable: Stories should avoid too much detail and be kept flexible
- Valuable: Users get some value from the story
- Estimatable: The team can use them to plan project timelines
- Small: Smaller user stories are easier to estimate than larger ones
- Testable: Everyone should be able to document the “definition of done” (how we know the user story is done) and the acceptance criteria.
4. Defining Acceptance Criteria
Acceptance criteria are used to define the specifics of a user story and are written in clear, non-technical language. Developers use these details to better understand the deeper details and requirements of the user story. Testers also use the acceptance criteria as a checklist when testing the application.
Acceptance criteria are often defined first by the business analyst, and when the project moves onto development, it is further defined by the whole team. When developers contribute to acceptance criteria, it ensures that the details of the user story are feasible and can be effectively implemented.
At FreshWorks, when writing acceptance criteria, two important things we try to remember are:
- To define it before development starts. It is important to define the acceptance criteria before a user story starts being developed by a developer. If we define it before development, we’re more likely to capture the user intent, rather than the development reality. If it is done after the fact, all we have achieved is a list of what is currently there, whether or not it solves the user’s problem/addresses their need.
- To remove all ambiguity. It is important to consider edge cases (Like: “What if they log out in the middle of a transaction?” or “What if they want to use the app in a different time zone?”) and ensure each route is thought of. This creates the best user experience and allows for the most comprehensive test coverage.
What Does A Completed Set of User Stories Look Like?
The following is an example of a document we create in the discovery phase of a project. We work in Google Sheets because it allows very easy collaboration between our team and the client. As you can see, not all user stories have a “so that…” section, because the user story itself can be self-explanatory, but other times it can add another level of understanding about the user’s goals.
Overall, user stories are a key part in creating a useful user-oriented application. As long as you have a very clear understanding of your users, you will be able to create a great set of user stories that outlines the goals a user has for your application.
At FreshWorks, detailed and comprehensive user stories are one of the pillars in our discovery process. We can perform extensive user research and interview stakeholders when creating user stories, which ensures that we achieve the desired business value and desired objectives for your mobile or web application. Research and analysis are part of what makes our process comprehensive and enables us to deliver great results on every project. Reach out to us to learn more about how we can create a remarkable digital experience for your users.
Originally published at freshworks.io.
