The Essential Guide to Effective User Story Writing
Effective user story writing is essential if you want to build and run a service that meets user needs. For team members, user stories are important guidelines that help track everything they need to do and encourage them to think about work from a user’s perspective.
What is a user story?
A user story is a short sentence which briefs a need or piece of functionality in the language of the end user. It sums up what the requirement or goal is and the reason for it.
Unlike complicated requirements and specification documents, user stories can be written at different levels of detail which allows to use them in discussions with both your client and project team.
In other words, instead of writing a massive report, you capture and present user requirements in an easily digestible way.
Basic user story construct
There is a basic construct followed by people writing user stories: As a [user role], I want to [goal], so I can [reason]. This helps to ensure that the requirement is feature-oriented and covers who, what and why.
After capturing requirements in user stories, they should be written on a card to enable team collaboration and make progress visible. Traditionally, the card includes 3 parts:
- Card (name/description of the user story, estimated size, etc.)
- Conversation (notes about the feature and how it should function, aka anything that can explain the feature)
- Confirmation (the tests that will show the feature is complete)
Remember that user stories should be kept small enough to fit on a card. It helps to ensure that requirements are broken into small, manageable pieces of functionality (individual features).
What makes a good user story?
Bill Wake, author of ‘eXtreme Programming Explored’, suggests the ‘INVEST’ acronym as a simple way to remember what makes a good user story.
The user story should be as self-contained as possible (ideally, in a way that there is no inherent dependency on another user story).
User stories are not detailed specifications. They are just reminders of features and should leave space for teams to discuss details and collaborate.
User stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.
You should always be able to estimate the size of a user story. In other words, user stories should provide enough information to estimate, without being too detailed.
User stories should be small. When they become too big, it becomes almost impossible to plan/task/prioritise with a certain level of certainty.
User stories should provide the necessary information to make test development possible.