What is a user story?

User story: definition and structure

A user story captures a requirement in one sentence: who wants something, what should be possible and why? The classic form is “As a [role], I want [function], so that [benefit].” The benefit is deliberately included, because it shows how important the requirement is and whether simpler solutions exist.

A story comes with acceptance criteria, that is, clear, testable conditions for when it counts as fulfilled. Larger undertakings are described as an “epic” and broken down into individual stories. All stories are collected in the backlog, which the Product Owner prioritizes by value. That way, everyone can see what comes next and why.

Good user stories: the INVEST principle

The acronym INVEST serves as a guide: independent, negotiable, valuable, estimable, small and testable. A story should be doable in a few days and refined in conversation between the business side and development, rather than being treated as rigid contract text.

Acceptance criteria are often written in the pattern “Given – When – Then”: given a logged-in technician, when he opens a job, then he sees the address, contact person and materials list. Such sentences can be proofread by specialists and later used directly as test cases. That prevents misunderstandings between the business side and development.

• Name the role specifically instead of “the user” in general
• State the goal and the benefit in one sentence
• Write acceptance criteria so they can be tested
• Cut the story so that it can be finished within one cycle
• Do not prescribe a technical solution where the goal is enough

Real-world example: an employee app for a plumbing business

A plumbing business plans an app for the job site. Instead of a long feature list, stories like these emerge: “As a technician, I want to record my working hours directly on site, so that I don’t have to enter slips of paper in the evening.” Or: “As an office manager, I want to see which jobs were completed today, so that I can write invoices faster.”

In the discussion of the first story, it turns out that some job sites have no reception. This leads to a requirement of its own: entries must also be possible offline. Without the user perspective, this would only have been noticed after launch, with the corresponding rework.

Limits, mistakes and imple­menta­tion

User stories do not replace documentation: complex rules, interfaces or legal requirements need additional descriptions. Typical mistakes are stories that are hidden solution specifications (“As a user, I want a dropdown …”), stories that are too large, missing acceptance criteria and stories that development writes without consulting the users.

Nano Concepts works out requirements together with your business departments, formulates them as user stories with acceptance criteria and uses them as the basis for the quote, implementation and acceptance. For larger projects, it is worth collecting the most important stories together in a short workshop. That way, everyone involved knows what is being built and how success is measured.