User Stories and Acceptance Criteria: A Practical Guide for Business Analysts

Written by Jude Mahoney

Agile Delivery Lead | Business Analyst Mentor | 20 Years Experience

LinkedIn: Jude Mahoney

Think about how easy it is to misunderstand a text message.

Someone close to you sends a short message. You read it in a particular tone, interpret what they meant and perhaps become irritated by it. Later you speak to them and discover that they meant something completely different. The words were there, but the tone, context, intention and meaning you attached to them were not necessarily the same as those intended by the person who wrote them.

If misunderstandings can happen between two people who know each other extremely well, imagine what can happen when somebody tries to describe a complicated business requirement in a twenty-page functional specification.

The Business Analyst writes it. A stakeholder reads it. A developer interprets it. A tester interprets it slightly differently. Three months later somebody discovers that four people believed the same paragraph meant four subtly different things.

That is one of the problems user stories were intended to help solve.

Their real strength is not the familiar:

As a... I want... So that...

format.

The real strength is that a user story gives people something small enough to talk about.

Instead of trying to capture every detail of a requirement in a large specification and hoping everybody interprets the written words in precisely the same way, the team captures the need simply, discusses the detail together and then records enough acceptance criteria to confirm what everybody has agreed.

This idea is often described through the Three Cs of user stories: Card, Conversation and Confirmation.

Card → Conversation → Confirmation

The Card captures the need simply. The Conversation creates the detailed shared understanding. The Confirmation establishes how everyone will know that the need has been satisfied.

For a Business Analyst, understanding that principle is considerably more valuable than simply learning how to write “As a, I want, so that”.

Why the Written Word Is Not Enough

Detailed specifications can create a dangerous illusion of precision.

If a document contains 80 pages of requirements, diagrams and numbered statements, it can feel definitive. Everything has been written down, reviewed and approved, so surely everybody understands what needs to be built.

Not necessarily.

Written language requires interpretation.

Consider a simple statement:

The customer may cancel an order before dispatch.

It sounds clear.

Now give that sentence to a Product Owner, developer, tester and warehouse manager.

What exactly does before dispatch mean? Before somebody starts picking the order? Before it is packed? Before a shipping label is generated? Before the courier collects it? Before the system changes the status to “Dispatched”?

What does may cancel mean? Is cancellation immediate? Does somebody approve it? Are all products eligible? What happens to payment? What if the warehouse is already processing it?

The sentence isn't necessarily badly written.

The problem is that human beings naturally fill gaps with their own assumptions.

That happens constantly in ordinary life. A friend sends:

“Fine. Do whatever you want.”

Depending on the relationship and context, you could interpret that in several very different ways.

A conversation usually resolves the ambiguity rather quickly.

Software requirements are no different in principle, except that misunderstandings can cost considerably more money.

This is why the conversation surrounding a user story matters so much.

The Three Cs: Card, Conversation and Confirmation

The Three Cs provide a simple way of understanding what a user story is actually for.

1. Card: Capture the Need Simply

Historically, user stories were deliberately small enough to fit onto an index card.

That physical limitation encouraged brevity.

The Card was not intended to contain every business rule, scenario, exception, validation rule and implementation detail. It acted as a reminder that a conversation needed to happen.

Today the physical card may have become a Jira ticket, Azure DevOps item or something similar, but the principle remains useful.

Suppose the requirement is:

As a customer, I want to change my delivery address before dispatch so that my order is sent to the correct location.

That gives us enough information to understand the basic need.

It tells us:

• Who: customer

• What: change delivery address

• When: before dispatch

• Why: ensure delivery goes to the correct place

It does not tell us everything required to build the functionality.

It isn't supposed to.

That comes next.

2. Conversation: This Is Where Much of the Analysis Happens

This is arguably the most important of the Three Cs.

The user story gives the team something specific to discuss.

The BA might bring the story into a refinement session with the Product Owner, developer and tester. The conversation begins:

BA: “The customer needs to be able to change the delivery address before dispatch.”

A developer asks:

“What exactly counts as dispatched?”

Good question.

The Product Owner explains that once warehouse picking begins, the delivery address can no longer safely be changed.

A tester asks:

“What if the new postcode isn't covered by the same delivery service?”

Another good question.

Someone else asks whether changing the address could affect delivery charges.

The BA asks whether there are restrictions for high-value orders.

The developer explains that the address is also sent to a third-party fulfilment platform.

The original sentence has now produced a valuable conversation.

Perhaps the team discovers:

• customers must be authenticated;

• the order must belong to the customer;

• address changes are allowed only before warehouse processing;

• some high-value orders require additional verification;

• changing postcode can affect delivery options;

• the fulfilment system must receive the amended address;

• customers need confirmation when the change succeeds;

• the customer needs a useful explanation when a change is no longer possible.

None of that understanding existed simply because somebody wrote:

“As a customer, I want to change my address...”

It emerged through analysis and conversation.

That is the point.

Conversation Is Often Safer Than Trying to Write Everything Down First

There is a profound practical advantage here for Business Analysts.

It is often much easier to talk through a complicated need with the people who understand different parts of it than it is for one analyst to attempt to anticipate every detail and encode it into a complex functional specification.

The developer asks questions from a technical perspective. The tester naturally thinks about boundaries and failure. The Product Owner understands priorities and value. The BA connects those perspectives to the business need, rules, processes and stakeholders.

Misunderstandings surface immediately.

Someone says:

“Hang on, that's not what I thought we meant.”

Excellent.

You want that sentence before development, not during UAT or after release.

This doesn't mean documentation becomes unnecessary. Important decisions, rules and behaviours still need to be captured.

The difference is that the documentation records understanding created through collaboration rather than attempting to replace collaboration altogether.

3. Confirmation: How Will We Know We've Got It Right?

The conversation produces shared understanding.

Confirmation makes that understanding testable.

This is where acceptance criteria become particularly valuable.

Suppose the team agrees that an address can be changed only when the customer is authenticated, the order belongs to them and warehouse processing has not begun.

Acceptance criteria can capture those agreed conditions.

For example:

• An authenticated customer can change the delivery address for their own eligible order.

• The new address must pass address validation.

• The address cannot be changed once warehouse processing has begun.

• A successful change updates the order before fulfilment.

• The customer receives confirmation that the address has been changed.

• Where the address cannot be changed, the customer is told why.

Now the story has moved through all Three Cs:

CARD
A concise statement of the need.

CONVERSATION
The team explores what that need actually means.

CONFIRMATION
Acceptance criteria record the important conditions that demonstrate the requirement has been satisfied.

That is much closer to the real purpose of user stories.

The Familiar User Story Format

The common structure remains useful:

As a [type of user], I want [capability], so that [benefit or outcome].

For example:

As a registered customer, I want to view the current status of my order so that I know when to expect delivery.

Each part has a purpose. The first identifies who has the need, the second describes the capability and the third explains why it matters.

The “so that” is particularly useful because it exposes weak understanding.

Compare:

As a customer, I want to update my address so that my address is updated.

with:

As a customer, I want to update my delivery address before dispatch so that my order is sent to the correct location.

The first merely repeats itself.

The second contains a genuine outcome and immediately exposes something worth discussing: what does before dispatch mean?

A good story should generate useful questions.

Don't Worship the Format

Not every requirement needs to become “As a... I want... So that...”.

Consider:

As a system, I want to archive transaction records after seven years so that I comply with the retention policy.

Systems don't want things.

The actual requirement concerns data retention and possibly a regulatory or business rule. It may be clearer to express it directly.

User stories are a tool for creating shared understanding, not a grammatical law.

If forcing a requirement into the format makes it less clear, don't force it.

Acceptance Criteria: Turning Understanding into Something Testable

Acceptance criteria define what must be true for the story to be accepted.

They should emerge from analysis and conversation rather than being invented afterwards because Jira happens to contain an Acceptance Criteria field.

There is no correct number. A simple requirement may need two criteria. A complicated business rule might need ten, or it may be better represented using a decision table.

A useful starting question is:

What must be true for us to agree that this need has been satisfied?

Then deliberately explore alternatives:

What happens when it isn't true?

That second question is where Boolean logic becomes extremely useful.

Using Boolean Logic to Analyse Acceptance Criteria

Business rules frequently contain conditions with two states:

TRUE or FALSE

A customer is authenticated or they are not. An account is active or inactive. An order has been dispatched or it hasn't. A payment has been authorised or it hasn't.

Thinking about both states prevents requirements from describing only the happy path.

Suppose:

The customer can change their delivery address if the order has not been dispatched.

We can express this simply:

Order dispatched = FALSE → Address change permitted

Now test the opposite state:

Order dispatched = TRUE → Address change not permitted

That sounds obvious once written down, but the FALSE side of business rules is remarkably easy to overlook.

AND Logic

Suppose an address change is permitted only when all of the following apply:

• the customer is authenticated;

• the order belongs to the customer;

• the order has not entered warehouse processing.

That is AND logic:

Authenticated = TRUE
AND Own order = TRUE
AND Warehouse processing = FALSE
→ Address change permitted

A simple decision table makes the behaviour much easier to examine:

Authenticated	Own order	Processing started	Change address?
TRUE	TRUE	FALSE	YES
TRUE	TRUE	TRUE	NO
TRUE	FALSE	FALSE	NO
FALSE	TRUE	FALSE	NO

Now the team can see the rule rather than interpreting a paragraph about it.

OR Logic

Imagine identity can be verified using either an email code or an SMS code.

The rule becomes:

Email verified = TRUE OR SMS verified = TRUE → Identity verified

Email verified	SMS verified	Identity verified?
TRUE	FALSE	YES
FALSE	TRUE	YES
TRUE	TRUE	YES
FALSE	FALSE	NO

Again, the logic exposes ambiguity.

Do we genuinely mean OR? Could either method work independently? Or does the business actually require both?

That is precisely the sort of misunderstanding the BA should uncover before development.

Combining AND and OR

Real requirements can become more complicated.

Suppose an automatic refund is permitted when the purchase is within 30 days AND the product is returnable AND either the value is below £100 OR the customer has premium status.

The logic becomes:

Within 30 days AND Returnable AND (Below £100 OR Premium) → Automatic refund

At this point, trying to explain every possible combination in prose becomes increasingly dangerous.

Use a decision table.

This is another important BA lesson: choose the representation that makes the requirement easiest to understand.

Using BDD for Acceptance Criteria

Behaviour-Driven Development gives us another useful way of expressing agreed behaviour:

GIVEN → WHEN → THEN

The structure is straightforward:

• GIVEN establishes the starting context.

• WHEN describes the action or event.

• THEN describes the expected result.

Returning to our delivery-address story:

Successful address change

GIVEN the customer is authenticated
AND the order belongs to the customer
AND warehouse processing has not begun
WHEN the customer submits a valid new delivery address
THEN the delivery address is updated
AND the customer receives confirmation of the change.

Now test the opposite state.

Order already being processed

GIVEN the customer is authenticated
AND the order belongs to the customer
AND warehouse processing has begun
WHEN the customer attempts to change the delivery address
THEN the address is not changed
AND the customer is informed that the delivery address can no longer be amended.

And invalid information:

Invalid address

GIVEN the customer is permitted to change the delivery address
WHEN the customer submits an invalid address
THEN the address is not updated
AND the customer is told which information needs correcting.

These scenarios are readable by business stakeholders, developers and testers alike.

That is part of their value.

Boolean Logic and BDD Work Extremely Well Together

These techniques are not alternatives.

Boolean logic helps the BA discover the states and combinations that matter. BDD helps the team describe important combinations as understandable behaviour.

A practical sequence is:

Identify conditions → Explore TRUE/FALSE states → Test combinations → Establish expected outcomes → Express important scenarios using GIVEN/WHEN/THEN

For example, Boolean analysis may reveal:

Authenticated	Own order	Processing started	Outcome
TRUE	TRUE	FALSE	Change permitted
TRUE	TRUE	TRUE	Change prevented
TRUE	FALSE	FALSE	Change prevented
FALSE	TRUE	FALSE	Authentication required

The team can then turn the meaningful combinations into BDD scenarios.

You do not need a GIVEN/WHEN/THEN scenario for every mathematically possible combination. If six Boolean conditions exist, there could theoretically be 64 combinations. Creating 64 scenarios would probably make the requirement harder rather than easier to understand.

Use judgement. Group equivalent outcomes, eliminate impossible states and use a decision table where it communicates complex logic more clearly.

The objective is not maximum documentation.

It is minimum ambiguity.

Don't Forget the Unhappy Paths

Requirements naturally gravitate towards success. The customer enters valid information, the payment succeeds, the integration responds and the order exists.

Reality is less cooperative.

When analysing acceptance criteria, deliberately consider invalid information, missing data, insufficient permissions, unavailable services, duplicate actions, state changes and important boundaries.

Suppose refunds are permitted “within 30 days”.

What happens on exactly day 30? What about day 31? From which event are the 30 days calculated: purchase, payment, dispatch or delivery?

A requirement can look perfectly clear until somebody tests its boundaries.

This is another reason the Conversation is so important. A tester asking, “What happens on day 30?” during refinement can expose ambiguity that survived several paragraphs of written specification.

Use Examples to Expose Ambiguity

Specific examples are remarkably good at testing apparently clear requirements.

A stakeholder says:

“Premium customers can return products for 60 days.”

Ask whether Sarah, a premium customer who purchased 59 days ago, can return the product.

Yes.

What about exactly 60 days?

Probably.

What if Sarah was a premium customer when she purchased it but isn't now?

The answer becomes less immediate.

What if she bought it as a standard customer and upgraded yesterday?

Now we are discovering the actual business rule.

This is analysis.

Examples force abstract language to confront real situations, and that often exposes assumptions much faster than adding another paragraph to a specification.

The Conversation Should Include the Delivery Team

The BA should not disappear, write a collection of supposedly perfect stories and then present them to developers and testers as finished requirements.

The people who build and test the solution possess knowledge that improves the analysis.

A developer might expose a technical dependency. A tester may identify a missing negative scenario. UX may challenge an assumption about user behaviour. The Product Owner may realise that an existing business rule is no longer appropriate.

This is why refinement can be so valuable when it is used properly.

Imagine the story says:

Customer can cancel an eligible order online.

A developer asks:

“What happens if cancellation is requested at exactly the same time the warehouse starts processing the order?”

That is not an annoying technical question delaying the sprint.

It may expose a race condition with a genuine customer and financial impact.

Talk about it.

Resolve it.

Then capture the resulting behaviour sufficiently clearly for everybody to understand what has been agreed.

Card → Conversation → Confirmation.

Don't Turn Acceptance Criteria into Another Functional Specification

There is an irony worth avoiding.

Teams sometimes move away from enormous functional specifications only to create user stories containing two pages of description and 37 acceptance criteria.

The Jira ticket becomes the functional specification.

That misses much of the point.

Capture what needs to remain durable: important rules, decisions, behaviours, scenarios and boundaries. Use diagrams, decision tables or supporting material where those communicate something better than prose.

But don't try to replace human interaction with ever more elaborate written requirements.

Remember the confusing message from your friend.

You could respond by sending them a 2,000-word clarification.

Or you could call them.

In complex delivery environments, conversation is itself an analytical tool.

A Structured Approach to User Stories and Acceptance Criteria

A practical BA approach looks like this:

Stage	Key question	Typical activity	Output
1. Problem	What are we actually trying to solve?	Research and analysis	Problem understanding
2. User	Who has the need?	User/stakeholder analysis	Meaningful actor
3. Value	Why does it matter?	Outcome analysis	Clear benefit
4. Card	How can we capture the need simply?	Story drafting	Concise user story
5. Conversation	What does this really mean?	Collaborative analysis/refinement	Shared understanding
6. Rules	What conditions govern it?	Business-rule analysis	Rules and constraints
7. Logic	What happens in different states?	Boolean analysis/decision tables	Logical outcomes
8. Confirmation	How will we know it works?	Acceptance criteria/BDD	Testable behaviour
9. Exceptions	What happens outside the happy path?	Boundary/exception analysis	Negative scenarios
10. Validate	Did we satisfy the original need?	Testing and review	Accepted outcome

In shorthand:

PROBLEM → USER → VALUE → CARD → CONVERSATION → LOGIC → CONFIRMATION → VALIDATE

Notice how little of that process is simply “writing a user story”.

A Complete Worked Example

Suppose a stakeholder tells you:

“Customers need to be able to cancel orders online.”

You could immediately create:

As a customer, I want to cancel my order online so that I don't need to contact Customer Service.

That's the Card.

Now have the Conversation.

Why is this needed? Customer Service receives thousands of cancellation calls. Which orders can be cancelled? Apparently those that have not entered warehouse processing. Are all products eligible? No; personalised products cannot be cancelled once production begins. What about payment? Authorised payments need to be reversed. How does the customer know cancellation succeeded? They need confirmation.

A developer asks how quickly the warehouse receives the cancellation. A tester asks what happens when the customer tries to cancel somebody else's order. Operations explains that certain orders can enter processing within minutes.

The requirement is becoming clearer because people are talking about it.

Now analyse the logic:

Authenticated	Own order	Cancellation state valid	Product eligible	Outcome
TRUE	TRUE	TRUE	TRUE	Cancellation permitted
TRUE	TRUE	FALSE	TRUE	Cancellation prevented
TRUE	FALSE	TRUE	TRUE	Cancellation prevented
FALSE	TRUE	TRUE	TRUE	Authentication required
TRUE	TRUE	TRUE	FALSE	Cancellation prevented

That supports Confirmation through acceptance criteria and BDD.

Successful cancellation

GIVEN the customer is authenticated
AND the order belongs to the customer
AND the order remains eligible for cancellation
WHEN the customer confirms cancellation
THEN the order is cancelled
AND the customer receives confirmation.

Warehouse processing has begun

GIVEN the customer is authenticated
AND the order belongs to the customer
AND warehouse processing has begun
WHEN the customer attempts to cancel the order
THEN cancellation is prevented
AND the customer is informed that the order can no longer be cancelled online.

We have moved from a vague request to something the team genuinely understands.

The clever part wasn't writing:

As a... I want... So that...

The valuable part was everything the Card caused people to talk about.

Common Mistakes with User Stories and Acceptance Criteria

There are several signs that the technique is being used mechanically rather than analytically:

• Treating the Card as the complete requirement: the conversation never really happens.

• Writing stories before understanding the problem: the team captures a proposed solution rather than analysing the need.

• Using “As a user” everywhere: meaningful distinctions between different actors disappear.

• Writing meaningless “so that” statements: the benefit merely repeats the capability.

• Trying to put everything into the story: a supposedly lightweight requirement becomes another functional specification.

• Creating acceptance criteria to fill a field: criteria are invented rather than derived from analysis.

• Only documenting successful behaviour: FALSE states, failures and exceptions remain undefined.

• Misunderstanding AND and OR: combinations of rules create behaviour nobody intended.

• Using BDD mechanically: simple requirements become unnecessarily verbose.

• Treating acceptance criteria as technical tasks: implementation steps replace expected business behaviour.

• Ignoring boundaries: apparently simple rules such as “within 30 days” remain ambiguous.

• Treating the written requirement as unquestionable: new discoveries are ignored because they weren't on the original Card.

The Three Cs protect against many of these problems because they remind us that writing the story is only the beginning.

A Practical Checklist

Before bringing a story into refinement, make sure you understand enough about the problem, user and desired value to have a useful conversation. The Card should capture the need concisely rather than attempting to document every conceivable detail.

During the Conversation, encourage questions. Explore business rules, dependencies, assumptions, different states and boundaries. Let developers, testers, Product, UX and other relevant people challenge the emerging understanding. A moment of disagreement in refinement can save weeks of misunderstanding later.

For Confirmation, capture the important conditions and expected behaviours. Use simple acceptance criteria where they are sufficient, Boolean analysis where TRUE/FALSE states expose useful logic, decision tables where combinations become complicated and BDD where context and behaviour are best understood as scenarios.

Then ask the most important question:

Does everybody mean the same thing now?

Because that is the problem all this is ultimately trying to solve.

User Stories Are About Communication, Not Jira

User stories are sometimes taught as though their great innovation was reducing a requirement to one sentence.

It wasn't.

Their deeper value is that they recognise a fundamental truth about complex work: human beings understand complicated things better when they can discuss them, question them, challenge them and use examples than when one person attempts to perfectly describe everything for everybody else to interpret later.

We experience this outside work constantly. A badly interpreted WhatsApp message can cause an argument between two people who have known each other for twenty years. A five-minute conversation can reveal that neither person meant what the other thought they meant.

Now imagine the same problem involving business stakeholders, analysts, designers, developers and testers trying to describe the behaviour of a complicated system.

The answer is not necessarily another fifty pages of specification.

Capture the need simply.

Talk about it properly.

Confirm what you agreed.

Card. Conversation. Confirmation.

Acceptance criteria, Boolean logic and BDD then give the BA practical ways to make that shared understanding precise enough to build and test without losing the collaborative advantage that made user stories useful in the first place.

Developing Your User Story and Acceptance Criteria Skills

Memorising As a... I want... So that..., the Three Cs and GIVEN/WHEN/THEN is straightforward. The harder skill is sitting with a Product Owner, developer and tester while an apparently simple requirement starts producing difficult questions, and knowing how to analyse what emerges.

That requires practical experience with ambiguous requirements, conflicting rules, edge cases and stakeholders who may themselves have different interpretations of what is needed.

Elisto's Business Analyst training focuses on exactly that practical side of Business Analysis. User stories and acceptance criteria are taught as tools for analysing and communicating real requirements, rather than templates to memorise.

The Knowledge Hub can show you the structure.

The deeper capability comes from learning how to turn a small Card into a good Conversation, and that Conversation into clear Confirmation.

That is where the real value of user stories lies.