top of page

Ep13: What are User Stories and Acceptance Criteria?

Today, let me explain User Stories and Acceptance Criteria.

A User Story is a general explanation of parts of a solution, written from the perspective of the end user. Its to articulate how a feature will provide value to customers/stakeholders.
Image credit: Jeff Patton

E.g. As an Bank app user, I want to be able to check my balance, so that I know whether I’ve been paid.

The aim is to create a shared understanding with all involved. This is rarely achieved by sharing a detailed document, as we tend to interpret things differently. A better way is to share our understanding with words and images, and combining and refining our ideas.

The User Stories should start a conversation.

Along the way, everyone is encouraged to generate notes, use cases, UI designs etc; these mementos help you remember the details discussed. Jeff Patton uses the example of holiday pics: If you were there, you know the details you don’t see on the image. People that weren’t, won’t know. A picture truly speaks more than a thousand words!

Why use User Stories?

Product Backlog Refinements become more efficient due to the shared understanding. Teams tend to embrace rather than fear the unknowns, and it helps speed up the delivery of a feature.

What are Acceptance Criteria?

Acceptance Criteria are the conditions a solution must meet to be accepted by the user. They help ensure stakeholders and users are satisfied with what they get. Acceptance Criteria should be answerable in a yes/no format, measurable and serve as a basis for tests.

E.g. bank balance is displayed, recent deposits displayed.

The challenge with User Stories is to find the right balance between working out details, and getting on with building it.

Too much detail, and you risk wasting time, especially if the Story is dropped. Too little detail, and it slows down the build, whilst the team waits for answers.

You address the required level of detail during Backlog Refinement, and during the Retro you can assess how you went with the balance between timing and detail, and make tweaks for the next Sprint.

For this post I used information from and It was first published here.


bottom of page