USER STORY
CITATIONS IN BUTTONS
Embedded Files
What is a User Story?
What is a User Story?
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?
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?
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?
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:
VALIDATE THE NEEDS OF THE USERS
CREATE EPICS
WRITE USER STORIES FROM REQUIREMENTS
DEFINE ACCEPTANCE CRITERIA
1. Validate the Needs of the Users
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
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.
A good user story should be Independent, Negotiable, Valuable, Estimatible, Small and Testable
4. Defining 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?
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.
Here’s what a set of user stories could look like.
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 make 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.
In software development and product management, a user story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards, Post-it notes, or digitally in project management software.[1] Depending on the project, user stories may be written by different stakeholders like client, user, manager, or development team.
User stories are a type of boundary object. They facilitate sensemaking and communication; and may help software teams document their understanding of the system and its context.[2]
CONFIDENTIALITY / COPYRIGHT NOTICE: This site and my information and any attachments contains the PRIVILEGED AND CONFIDENTIAL INFORMATION of Fred Finkelstein & Irondesigner DBA / LLC mutually, Inc., its affiliated corporations or legal entities, and is intended only for the use of the individual(s) named above. If you are not the intended recipient of this e-mail or invited to this site, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any unlawful interception, dissemination, disclosure, printing or copying of this e-mail or site or any attachments is strictly prohibited under the Electronics Communication Privacy Act (ECPA), 18 USCA 2510, 18 USCA 2511, and any applicable laws. If you have received this e-mail or viewing this site in error, please delete or destroy it & close down, including all attachments or copies, and immediately notify us by e-mail at mechanicalengrg@gmail.com
Page updated
Google Sites
Report abuse