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:
1 | 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.
Tip
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.