Term
User story
A short description of a requirement from the user's point of view in the form „as a role I want a feature so that I get a benefit“. It helps the team understand why something is being built and is complemented by acceptance criteria.
Updated
What it means
A user story is a short description of a requirement from the user's point of view, in the form as a role I want a feature so that I get a benefit. For example: as a sole trader I want to upload a photo of a receipt in the app so that I do not have to bring documents to my accountant in person. It is not a technical specification but an expression of need.
User stories are used mainly in agile software development, for example in Scrum. They help the team understand why something is being built and for whom, and keep the focus on customer value rather than on a list of technical tasks.
Each user story is complemented by acceptance criteria that define when the requirement is met. For instance, the app accepts photos in JPG and PDF, shows a confirmation and the document appears in the processing queue. The criteria prevent misunderstandings between the client and the developers.
How it works in practice
User stories are collected in the product backlog, where the product owner orders them by priority and value. At the start of each sprint, the team picks those it can finish in the period and breaks them down into specific technical tasks.
A good user story is small enough to complete in one sprint, independent of others, estimable and testable. Requirements that are too large, known as epics, are split into smaller stories that deliver value step by step and can be validated with users sooner.
When building an MVP, user stories help define the minimum set of features that bring value to users. A company commissioning a custom app can use them to describe its needs clearly without knowing the technical details.
What to watch out for
A user story is not a contractual specification. In outsourced development at a fixed price, the scope and acceptance criteria must be precise enough, otherwise disputes arise over what was agreed. Agile cooperation therefore often uses a time and material model.
The most common mistake is writing stories from the system's or the developer's point of view, such as create a table in the database. Such an item says nothing about user value and makes prioritising harder. The role, the need and the benefit should always be clear.
Need the term explained on your own situation? Consulting from €55 / hour excl. VAT, depending on topic and complexity.