by David Nash

In the Agile Scrum process, a user story explains a product feature. Written from the end user’s perspective, it articulates how a feature will provide value to a customer. The operative word here is “user.” The story should reflect a specific user’s perspective, not what a developer should be creating. However, developers can break stories into tasks that detail exactly what they need to do to satisfy the story.

The user story should reflect a specific user’s perspective, not what a developer should be creating.

A user story has two main components: Description and Acceptance Criteria. The Description should answer three questions: Who, What, and Why. Frequently, user story writers will use the “As a <Who>, I need to <What> so that <Why>” format. The format isn’t as important as ensuring that the story possesses all the needed content. 

The Acceptance Testing is arguably the most important user story component. It lists all the items that must work correctly – and pass testing – so the product user can accept the story. The Acceptance Testing section in good user stories includes both positive and negative outcomes.

The Acceptance Testing is arguably the most important user story component.

User stories should be as “full-stack” as possible, including back-end, API, and front-end work. However, user stories also must be limited enough in scope for the feature to be developed in a reasonable time frame. User stories should not include any feature that isn’t functional yet. Doing so confuses users and testers and makes it harder to separate accomplishments from mock data. 

User stories make it easier to develop a feature (limit the scope), test it (detailed Acceptance Testing), and accept it (clear changes on the page). By following the guidance in this article, writers can create better stories – and Scrum team members can identify fixes to poorly written ones.