A User Story describes a feature, or requirement, that is to be implemented and is independent of a specific tool (i.e. JIRA, Rally, Trello, etc.). User stories are employed in various Agile frameworks including Scrum, Kanban, and Extreme Programming.
User stories should be written as small, independently, testable increments of the business need, and prioritized by the Product Owner. While Product Owners write functional user stories, the Scrum Team can contribute non-functional / technical stories. However, any non-functional user stories added to the Backlog must also be vetted and prioritized by the Product Owner. Overall, user stories should enable conversation between the Product Owner, Scrum Team, and business group(s).
Writing User Stories
During Sprint Grooming, groups of features / requirements, or Epics, are broken down into user stories by the Product Owner. Then Sprint Planning is used to estimate the level of effort to complete a user story through tasking by the Scrum Team.
The user story is a short, simple description of a feature or function written from the perspective of the end user:
As a [ type of user ], I want [ some goal, function ] so that [ some reason ].
An example:
As a Leasing Specialist, I want the ability to upload an SF-81 document so that I can attach it to my lease file.
When writing a user story, it requires key content:
- Description, or summary of the feature or requirement that meets the business need
- Acceptance criteria, or the actions necessary to call the user story “done,” in other words, meet the established Definition of Done (DoD)
- And any other items as identified by the team (e.g. Epic, Label, etc.) and within their tool of choice (e.g. JIRA, Rally, etc.),
- And most importantly, it should be:
User story independence is ensured when the delivery increment has been fully decomposed; this allows for the appropriate tasking, estimation, sizing, and testability of the effort. The Product Owner negotiates the prioritization of the functionality with the Scrum Team against user needs, while the value of the user story drives its priority.
Further, testability of the user story is captured in the acceptance criteria; it should denote the “The Who” (user), “The What” (capability), and “The Why” (outcome) of the increment. For additional detail on writing user stories, check out our User Story Examples, or review Defining When a Requirement is Complete on defining acceptance criteria.
