User Story

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

User Story

A short concrete statement that captures a functional requirement, who it is for and what its value is.

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

For example:

• As an instructor, I want to invite my students to the discussion board using a signup link, so that I don't have to add them one by one.

The role-goal-benefit format forces the stakeholders 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 you are thinking about user stories, it is important not to feel constrained too much by its 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 the story?
• 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."