User Story

One of the most widely used ways of capturing requirements in a format that's useful for engineers and customers are user stories. The user stories are short concrete documents that capture who a feature is for, what its value is, and how long it will take to build.

User stories are written in a format called the role-goal-benefit:

As a <type of user>, I want <some goal or objective> so that <benefit/value>

The role-goal-benefit forces the customer/developer to really think about who is going to benefit from a feature, what they're trying to achieve, and why they want to achieve that. By capturing a feature (functional requirement) in such a concrete way, it gives everyone an opportunity to really think about whether or not a feature is really worthwhile and adds real concrete value to a product.


When we're thinking about user stories it's important not to feel constrained too much by the process. One place that people find this constraining is in terms of role-goal-benefit. The role for our user stories don't always have to be human entities. They can also be back-end systems, third party servers, and other systems.

User story checklist

Getting user stories right is often challenging, especially for newcomers. Here is a set of guidelines to help you write effective user stories:

  • Keep them short, simple and independent from one another.
  • Write from the perspective of the user.
  • Make the value/benefit of the story clear - what is the reason for the story?
  • Describe one piece of functionality. If you must, break it into more stories
  • Write stories as a team.

Sample User Stories