Table of Contents
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]
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.
Action – The behavior of the system should be written as an action.
Benefits – The benefit should be a real-world result that is non-functional or external to the system.
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 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 |
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.
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.
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.
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!)
User Stories should be small enough that they are able to be completed within a sprint.
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
[1] https://en.wikipedia.org/wiki/User_story
Why Use Scrum? Why use scrum in software development? Here are some of the key…
Agile Manifesto for Software Development What is the Agile Manifesto? The Agile Manifesto is a…
ScrumAA Glossary ScrumAA Glossary Acceptance Criteria Details just what needs to be done for the…
Frequently Asked Questions in Scrum (FAQs) ScrumAA FAQs ScrumAA Frequently Asked Questions (FAQs) QuestionAnswerWhat is…
Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Scrum Events The Scrum Events Per Scrum…
Scrum Sprint Cancelling a Sprint Sprint Goal Scrum Sprint So what is the definition of…