User Story #

Recall a functional requirement is a single thing that the software has to do. For example, "send a confirmation email when a new user signs up" is a functional requirement.

One of the most widely used methods of capturing requirements in a format that's useful for all stakeholders is user stories.

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

The role-goal-benefit format forces the stakeholders to think about who is going to benefit from a feature, what they're trying to achieve, and why they want to achieve that.

Capturing a feature (functional requirement) in such a concrete way allows everyone to think about whether or not a feature is truly worthwhile and adds real concrete value to a product.

When you are thinking about user stories, it is important not to feel constrained too much by the role-goal-benefit format. For example, 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. Etc.

Getting user stories right is often challenging. 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 (usually a human who interacts with your application).
• Make the value/benefit of the story clear--what is the reason for having this feature?
• A user story should capture one functional requirement (or part of it). Otherwise, break it into several user stories.
• Write user stories as a team. As the saying goes "None of us is as smart as all of us."