User StoryAs a [user role] I [want/need/can/etc] [goal] so that [reason].
Core Principles
Use the customer’s language.
Write user stories as the user would ask for them. Don’t write your user stories as a list of to-dos from the perspective of your business. As the advocate for the user inside the building, use what you have learned from interacting directly with your users to share the way they think and talk about features and activities, not how you might organize them internally. Customers don’t care about your problems, they care about their problems.
The story is a discussion tool.
The user story is just the beginning of the conversation. Use it as a tool to start from, and a descriptor to later refer back to the conversation. Don’t try to communicate all the nuance of a user interaction in the draft of the user story alone. As Agile Alliance says: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Acceptance criteria is the result of discussion.
Similarly, don’t finalize your acceptance criteria in a vacuum before you have that discussion about what the user wants or needs with your team. Come up with a draft, but recognize that it may change. The acceptance criteria should be a result of discussing the user story with your development team, not a contract written unilaterally.
Link to business value.
Show why this user story matters for the business. This context means that the team working on each story can make decisions with the big picture in mind, which has both the benefit of making it easier to get on the same page, and the benefit of unlocking additional expertise from your development team that can lead to better solutions. The acceptance criteria is a good place to do this, and even better if you can tie it to specific metrics.
Checklist
- Can your user story provide value independent of other features or stories?
- Can your user story be implemented in multiple ways? Define the results, not the method of achieving them.
- Does your user story communicate how it is valuable to the user?
- Does your user story have enough detail to estimate the level of effort required to implement it?
- Is your user story small enough to be implemented in a 2-week (or whatever length you use) sprint?
- Is your acceptance criteria a binary pass/fail? You don’t want to rely on subjective criteria.