The Elements of a User Story in Agile Development

A user story is a brief expression of a feature in a desired capability told from an end-user perspective. The user story approach shifts the focus of the stakeholders from rigorously writing granular technical specifications of a feature to openly and collaboratively discussing them with the help of a cross-functional and self-organizing development team.

A user story usually reads something to this effect:

As a (user role), I want to (goal) so I can (reason).

Example: “As a manager, I want to download timecard reports so I can monitor staff attendance.”

It’s the stakeholders who write user stories. Since the stakeholders represent the Voice of the Customer (VoC), the task of writing the user story is better delegated to them than to anyone from the development team. The language of the user story should be simple enough that domain experts and developers can understand them.

User stories don’t have to be written in a formal document. Simple tools like sticky notes, notepads, or index cards will do. To facilitate planning and organization, they are posted on walls or carefully laid-out on tables.

User stories that cover huge amounts of functionality are called epics. They can be further broken down to

For example, the user story “As a user, I want to back up my entire hard drive…” can be split and articulated into the following user stories:

1. As a user, I want to rename files or folders so I can distinguish one file from another.
2. As a user, I want to delete unnecessary files or folders so I can save up on storage memory.

A list of user stories is called a product backlog.

One way to determine if your user story is written correctly is through the INVEST model:

Independent – A good user story has reduced dependencies. It makes for easier delegation of responsibilities.

Negotiable – As the development progresses, a team member or a stakeholder can add details or refine the user story.

Valuable – First and foremost, user stories provide value to the customer. No unnecessary features shall be included.

Estimable – User stories have to be estimated as big or small depending on factors like complexity, length of task, etc.

Small – Does the user story cover so many desired functionality? Can it be split further?

Testable – Must be verified and validated by a well-defined acceptance criteria.

True to the promise of the Agile methodology, a brief description or definition of “done” is appended every after user story. In daily stand ups, the product owner and the development team should be able to discuss the user story and clarify what “done” means. As he or she works on a user story, and by the collaborative nature of Agile, a team member can suggest adding or removing an acceptance criterion as the team expands their understanding of a project.

Bear in mind that user stories are narrative representations of completed work. It’s not a full description of the work and the requirements. It should not be mistaken with use cases which focus on the interaction between the user and the system.

User stories are there to express direct customer value. They naturally exhibit looseness of specifications to encourage collaboration between stakeholders and the development team.

To clarify, the details found in a user story is more defined than those found in the Use Case, but not as detailed as those contained in a software requirements specifications document.