What is a user story?
User stories are not part of any particular agile framework but are a complementary practice adopted by many agile teams as a format for expressing product requirements. Due to their simplicity and versatility, user stories have become the most popular form of product backlog item.
User stories typically follow a simple format:
As a <type of user>, I want <some functionality>, so that <business reason>
For example:
As a site member, I want to view the profiles of other members so that I can find others I might want to connect with.
Why use user stories?
Being written from the perspective of a user (As a <type of user>) emphasises the real-world value of the requirement, helping developers to understand the problem the proposed feature will solve without specifying technical implementation details.
User stories start life as simple descriptions of requirements which then evolve over time. At first, a story might be no more than a reminder to have a more detailed discussion once a team commits to building a feature. In this way, user stories are incomplete until the related discussions occur - encouraging collaboration between the product owner, development team, and business stakeholders, welcoming changing requirements.
Initial stories might be broad, high-level feature requirements (often referred to as Epics) before then being broken down in product backlog refinement into smaller, more targeted stories that can comfortably be completed within an iteration/sprint. As the stories are broken down, acceptance criteria are usually added to describe the conditions that need to be fulfilled for the story to be done.
Who writes user stories?
On a Scrum team, whilst it is the product owner’s responsibility to prioritise and maintain the product backlog, user stories can be written by anyone. Who actually writes the stories is less important than the process in which the requirements or features are progressed…again, collaboration is key! User stories provide the most value when written collaboratively between the product owner, development team, and stakeholders.
Finally, not everything on a product backlog needs to be a user story. User stories work well for capturing product functionality but might not work so well for more technical requirements. If you find yourself expressing user stories from the perspective of “a developer” or “a technical architect” then consider whether the user story format is really necessary. Don’t feel obliged to squeeze everything on your product backlog into a user story.