Agile Concepts: User Stories
User stories in Agile are a way of representing bits of functionality required by the stakeholders in such a way as to generate the maximum amount of discussion among team members, helping them work together to turn requirements into working software.
A story is a piece of functionality that can be developed in a single iteration (Scrum is not prescriptive about this but it is an effective way of thinking about stories), as opposed to an Epic which is a larger piece of functionality. Epics need to be decomposed into stories before they can be added to a sprint backlog.
Stories, Epics and Themes
These terms are used differently by Scrum and Agile teams but it can be incredibly useful to have a common language and understanding for what terms are describing.
An example would be:
Story: A single piece of functionality that is described in such a way that it could be developed in a single sprint
Epic: A large story
Feature/Theme: A collection of related stories or epics that represent a whole area of functionality e.g. login
The user story format
Representing a story as a user story involves writing it as a short statement in this form:
As a <user> I can <feature> so that <benefit>.
Writing stories in this way helps to keep the end user in mind at all times and is much more effective at promoting discussion than a passive description of a feature. It’s only through discussion that the team can rewrite and refine the user story to make it ready for development.
Writing user stories
Anyone can write a user story though in Scrum usually the bulk of the user stories in a product backlog are written by the Product Owner. This is because the PO is responsible for making sure a list of stories exists in the product backlog.
As the team’s representative of external stakeholders, it is also the Product Owner who prioritises user stories – largely determining the order in which they make it into sprints (though the final decision on this is always made by the Scrum team as a whole).
User stories are usually written on index cards or Post-its so that they can be stuck to the task board and their progress tracked through the sprint and so that the acceptance criteria can be written on the back.
The INVEST acronym provides a handy reminder that stories should be
Independent (of all others)
Negotiable (not a specific contract for features)
Valuable (or vertical)
Estimable (to a good approximation)
Small (so as to fit within an iteration)
Testable (in principle, even if there isn’t a test for it yet)
User stories should represent slices through the system – whole pieces of functionality created and tested that work end to end. (You shouldn’t have stories that just represent layout or just backend tasks unless unavoidable.)
Acceptance criteria, or conditions of satisfaction, are criteria that need to be met in order for the user story to be deemed complete.
The acceptance criteria flesh out a user story. There needs to be consensus among the team on what constitutes the definition of done for any story so they’re usually written during backlog refinement sessions. Acceptance criteria should be easy to reference along with the user story (e.g. written on the back of the card on which the user story is written).