A user story is a well-formed, short and simple description of a software requirement from the perspective of an end-user, written in an informal and natural language. It is the main artifact used in the agile software development process to capture user requirements.
User stories are either written by a product manager or a team member on behalf of the end-user, explaining the expected functionality from the system being developed. User stories are written to capture the most important elements of a requirement following a predefined template. The most commonly used user story template is called the connextra template where a user describes his role, his capabilities, and what benefits he expects to receive from the system using a single sentence.
Users should keep the following agile principles in mind when writing user stories.
1. Working software is the primary measure of progress.
2. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
High-quality user stories not only help project teams to clearly and precisely understand customer requirements but also make the project estimation and development process more efficient.
Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.
User stories are used as the primary way to capture high-level requirements in an agile development framework such as scrum and eXtreme programming (XP).
In the agile scrum framework, items in the product backlog are written as user stories because it helps the project teams and product owners to focus on the requirements from the perspective of the customer.
In eXtreme Programming (XP), user stories are used as criteria for product acceptance. The XP developers make use of the user stories to write acceptance tests that are done even before the product code is created. This approach saves time and ensures that the project code meets the client's acceptance criteria. User stories are also used in creating the estimates for release planning meetings in the XP framework.
The initial idea of the user story was generated by Dr. Alistair Cockburn in the late 90s. The way user stories are used has been developed by multiple practitioners since then, namely:
In 2001, the "Three C's" formula for user stories was proposed by Ron Jeffrey. The three C's stand for card, conservation, and confirmation.
In 2004, Mike Cohn published the book, User Stories Applied For Agile Software Development generalizing the user story principles.
In 2014, Jeff Patton and Peter Economy published the book User Story Mapping: Discover the Whole Story, Build the Right Product to introduce a new set of techniques to identify, structure and provide more visibility to user stories.
User story templates are created to identify who the end-user is, what the end-user wants and why they want it in a single sentence.
These are some examples of user stories written using different templates that are adopted by agile development teams to capture their requirements.
Template : As a <role> I can <capability>, so that <receive benefit>
Example: As a manager, I want to be able to view the status of ongoing work, so that I can plan when to deliver it to senior leadership.
Template : In order to <receive benefit> as a <role>, I can <goal/desire>
Example: To add new friends to my profile as a user, I should be able to send friend requests to other users.
Template : As a <role>, I can <goal/desire>, so that <why>
Example: As a follower, I want to be able to comment on the blog, so that I receive feedback from the author.
Template : As <who> <when> <where>, I <want> because <why>
Example: As a software tester when I log a defect under each developer's name, I want each of them to receive a notification because then the developer will then be aware of the defects I logged.
A well-formed user story can benefit the software development process in the following ways:
It helps to articulate precise user requirements: User stories are only successful if they include key elements such as a user's role, capabilities, desires, and goals in a single sentence. Having these elements clearly articulated makes them much more precise to the entire product team, ensuring that development stays laser-focused on end-user needs.
Better collaboration: User stories help to align all key stakeholders on not just what is being developed, but why.
Being able to reduce project risks: User stories are, at their very core, a user-centric tool for the product team. This helps to make sure that oversights and scope creep are caught early on.
These are some of the issues that agile development teams have faced when using user stories to capture requirements.
Less focus on non-functional requirements: User stories mainly focus on capturing functional requirements (i.e. how end-users directly interact with the system). The non-functional requirements such as performance, fault tolerance, usability, durability, modifiability, etc. may not be captured clearly or at all through the typical user story templates.
Difficult to scale for larger and more complex projects: The format of user stories is simple formats that focus on a single functionality. These can sometimes be difficult to scale up as a project becomes more complex.
Produce vague or incomplete requirements: As user stories are written in an informal and more natural language, the requirements may be too vague for engineers to work with. This can, however, be overcome with proper training in how to write great user stories.