What is a User Story?
- User Story Definition
- User Story Template: Role-Action-Benefit
- User Story Examples
- The 3 C’s (Card, Conversion, Confirmation) of User Stories
- How to Write Good User Story with INVEST Guidelines
Table of Contents
User Story Definition
So what is a User Story? In software development and product management, a User Story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system. They are often recorded on index cards, on Post-it notes, or digitally in project management software Depending on the project, user stories may be written by various stakeholders including clients, users, managers, or development team members.
User stories are a type of boundary object. They facilitate sense making and communication; that is, they help software teams organize their understanding of the system and its context. [1]
User Story Template: Role-Action-Benefit
A User story only capture the essential elements of a requirement in the format “As a <who> I want <what> so that <benefit>”:
As a Role {Who}, I want to Action {What}, (so that Benefit {Why})
Role – The user should be an actual human who interacts with the system.
- Be as specific as possible
- The development team is NOT a user
Action – The behavior of the system should be written as an action.
- Usually unique for each User Story
- The “system” is implied and does not get written in the story
- Active voice, not passive voice (“I can be notified”)
Benefits – The benefit should be a real-world result that is non-functional or external to the system.
- Many stories may share the same benefit statement.
- The benefit may be for other users or customers, not just for the user in the story [2]
User Story Examples
As <a recruiter> I can <post new jobs> so that <applicants can find those jobs via search>
As <a job seeker> I can <limit who sees my resume> so that <I have privacy>
The 3 C’s (Card, Conversion, Confirmation) of User Stories
- Card – a written description of the story used for planning and estimation.
- Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build shared understanding.
- Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.
How to Write Good User Story with INVEST Guidelines
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).
| I | Independent |
| N | Negotiable |
| V | Valuable |
| E | Estimable |
| S | Small |
| T | Testable |
I – Independent
Each User Story should represent a distinct and independent set of business value such that, were it released on its own, it would deliver incremental value over the previous state.
N – Negotiable
While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.
V – Valuable
The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.
E – Estimable
We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)
S – Small
User Stories should be small enough that they are able to be completed within a sprint.
T – Testable
All members of the team need a clear and precise way to verify whether or not a User Story has been completed
More articles from ScrumAA can be found here
Also check out Wikipedia for more information
References