Skip to content
Adrythm
Custom software

User story

user stories / story / acceptance criteria / INVEST

In short

A user story is a small slice of work written from the user's point of view, usually to a role, feature, reason template. The Agile Alliance defines it and offers INVEST as the quality test. The Scrum Guide, the framework most teams name, does not use the phrase at all.

The definition is about who decides, not about formatting. In consultation with the customer or product owner, the team divides up the work to be done into functional increments called user stories. The familiar wording follows from that: the role, feature, reason template is one of the most commonly recommended aids to write user stories, producing the as a, I want, so that shape that appears on every board.

There is a quality test, and it is more useful than the template. The acronym INVEST stands for a set of criteria used to assess the quality of a user story, and if the story fails to meet one of these criteria, the team may want to reword it. Notice the remedy: reword it. A bad story is a writing problem caught before anybody builds anything. A story too big to finish has its own name, because an epic is a large user story that cannot be delivered as defined within a single iteration.

The part worth insisting on is how anyone will know it is finished. The Given-When-Then formula is a template intended to guide the writing of acceptance tests for a user story: given some context, when some action is carried out, then a particular set of observable consequences should obtain. Until that exists, a story is a wish with a template around it.

Then the correction, which is worth knowing before somebody quotes a framework at you. The Scrum Guide does not use the phrase user story anywhere. Its unit is the Product Backlog, an emergent, ordered list of what is needed to improve the product, refined through Product Backlog refinement, the act of breaking down and further defining Product Backlog items into smaller more precise items. Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection. So writing in user stories is a widely used convention, not a rule anybody set.

In practice

If you are paying for the work, the acceptance criteria are the part to read. The story tells you what somebody wants and why. The criteria tell you what will be demonstrated and what will not, which is the same information you would want in any other quote for work you cannot inspect yourself.

Not the same as

A Product Backlog item
The framework's unit is the backlog item. A user story is one popular way of writing one, and a team can use the framework without ever writing a story.
A specification
A story is deliberately short, and the detail is expected to arrive in conversation and in the acceptance criteria rather than up front.

Why it matters to you

These are what you will be shown and asked to approve, often in a list of dozens. Approving the sentence is easy and means little. Approving the acceptance criteria is the moment where what you think you are buying and what the team will build are either the same thing or not, and it costs nothing to find out then rather than at the demonstration.

What to ask or check

  1. 01What are the acceptance criteria for this one, in given, when, then form?
  2. 02Which of these are really epics that have not been split yet?
  3. 03Who on our side reads these before the work starts?

What people get wrong

That the format is the standard. The Scrum Guide never uses the phrase, and the Agile Alliance presents the template as one of the most commonly recommended aids rather than as a requirement.

Red flags

  • Stories with no acceptance criteria attached.
  • A backlog of items too large to finish in one iteration, with no plan to split them.
  • Approval sought on the sentence rather than on how it will be demonstrated.

Who owns it

The team writes them in consultation with whoever speaks for the customer. That second role is usually the one nobody on the buying side has been given.

Where you will see it

On the board, in the sprint review, and in the list somebody asks you to sign off before work starts.

Product backlog

A product backlog is the ordered list of everything a team might build next. The Scrum Guide calls it the single source of work for the team. Agile Alliance is explicit that including an item does not guarantee it will be delivered, so being in the backlog is not a commitment.

Definition of done

A definition of done is the written list of conditions every piece of work must meet before anyone calls it finished. The Scrum Guide treats it as a gate: work that misses it cannot be released or even shown at the review. Agile Alliance warns that an unwritten one loses most of its value.

Sprint

A sprint is a fixed length block of development work, one month or less in the Scrum Guide and usually one to four weeks in practice. The fixed length is the point: it is what makes a completion estimate possible, and it decides what can be changed once the block has started.

Velocity

Velocity is the total of the estimates a team finished in one iteration. Agile Alliance is blunt about what it is not: a measurement made after the fact, not a budget or a forecast, with no meaningful comparison between teams and no such thing as an individual velocity.

Multi-factor authentication

Multi-factor authentication means proving who you are with two different kinds of evidence. NIST treats it as a level rather than a switch: at AAL2 two distinct factors are required and the application must offer a phishing-resistant option. Vendor lists run from text messages to passkeys, all labeled MFA.

API

An API is the way one piece of software talks to another without a person in the middle. MDN describes it as a contract between the application offering it and whatever uses it. The part that matters commercially is that the contract belongs to whoever publishes it, and it changes.

Want this explained against your own numbers?

Twenty minutes, a straight answer, and no follow-up sequence if you decide not to work with us.