What is a User Story?

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

User stories 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

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

References

[1] https://en.wikipedia.org/wiki/User_story

[2] https://www.visual-paradigm.com/scrum/3c-and-invest-guide/

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: