User Stories

What are User Stories in Agile/Scrum?

The best definition of a user story is:

Smallest piece of functionality, that has business value and can be tested and delivered independently

User stories are the building block of an Agile environment. Instead of building an entire feature, agile teams break down the feature and functionalities in small workable pieces.

User Story Template

Here is the template for the user story

As a [user]

I want [some ability]

so that [business value is generated]

Example of a user story:
As a registered user,
I want to change my password
So that I can keep my account secure.

In the above template, you can observe that a user story is logically divided into 3 parts; user, ability and business value.

  1. User
    • The user is the persona for whom we are building the functionality.
    • A good practice is to be specific about the type of user rather than mentioning simply ‘User’.
    • The type of user is defined through their role, their permissions, and their goals.
    • Here, a user can be customers, operators, developers, product owners, etc
  2. Ability
    • Here we describe the user’s ability and not the feature.
    • This section describes the intent of the user and what a user wants to do.
  3. Business Value
    • What is the benefit that a user gets?
    • This section describes the business value that is generated after the user performs the ability.

When are user stories written?

User stories are usually written at the start of the agile project. They are also written throughout the agile project.

Who writes user stories?

Anyone can write user stories. User stories are usually written by the product owner and the business analyst.

User stories are not requirements specification

The nature of user stories is such that one might mix it up as software requirement specification
The basic difference between user stories and other forms of requirements specification has to do with perspective and intent, both of which affect the level of detail.
Traditional requirements are criteria to which the system or business must adhere. They are usually created before the coding begins and are nearly always written as text. They often are thought of as constraints, conditions, or capabilities to which the system must conform.
A use case is a series of interactions by the user with the system and the response of the system. Use cases consist of two main components: use case diagrams and the text of the use case itself. Use cases and use case diagrams focus on the user, with a use case text itself written in a call-and-response format that shows action by the user, followed by the system’s response.
User stories focus on customer value. They don’t just assume a looseness of specification; they actually encourage it in order to foster a higher level of collaboration between the stakeholders and the team.
The actual work being done is fleshed out via collaboration revolving around the user story as system development progresses. As such the level of detail of a user story is ultimately higher than a use case but lower than a traditional requirement. In order to limit the scope, user stories have collaboratively developed acceptance criteria that define when the user story meets the stakeholder’s expectations.

Want to write good user stories?

Here are the basics you should know when it comes to a good user story. The simplest place to start is with Bill Wake’s INVEST acronym

INVEST stands for:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Need more information about INVEST? Check out the following page: