Writing better user stories and acceptance criteria

Few artefacts in digital delivery are as widely used — and as widely misunderstood — as user stories and acceptance criteria.

In theory, they provide a simple way to describe user needs and define what success looks like. In practice, they are often responsible for confusion, rework, delivery delays, and disagreements between teams. Stories become vague. Acceptance criteria become incomplete. Developers build something different from what stakeholders expected. Testers identify gaps late in delivery. Teams spend more time discussing what a story means than delivering it.

These problems are particularly significant in public sector digital programmes. Services often involve multiple user groups, complex policy requirements, legacy technology, accessibility obligations, and cross-government dependencies. A poorly written story can create uncertainty that ripples across an entire team.

This is where business analysts and service designers play a critical role. They help teams move beyond documenting requirements and instead create a shared understanding of user needs, service outcomes, and delivery expectations. Well-written stories and acceptance criteria become more than planning tools; they become communication tools that align multidisciplinary teams around a common goal.

The challenge is not writing more stories. The challenge is writing better ones.

What Makes a Great User Story?

Many teams are familiar with the standard format:

“As a user, I want to do something, so that I can achieve a goal.”

The format itself is useful, but it is not what makes a story valuable.

A common misconception is that a user story is simply a requirement written in a different way. In reality, a good story represents a conversation about a user need. The written text is merely a placeholder for that discussion.

The strongest stories focus on outcomes rather than features.

Consider the difference between these examples:

“As a citizen, I want a download button so that I can save my application.”

and

“As a citizen, I want to keep a copy of my application so that I can refer to it later.”

The first assumes a solution. The second describes a need. By focusing on the outcome rather than the implementation, the team retains flexibility to design the most effective solution.

Great stories are also grounded in evidence. They should emerge from user research, analytics, operational insight, stakeholder engagement, or policy understanding. When a team cannot explain where a story originated or which user need it addresses, there is a strong possibility that it should not exist at all.

Perhaps most importantly, a story should be understandable by everyone involved in delivery. If developers, testers, designers, analysts, and stakeholders interpret it differently, the story is not yet ready.

The best stories are often surprisingly simple. Their strength comes from the clarity of the thinking behind them rather than the volume of information they contain.

Ten Common Pitfalls and How to Avoid Them

Writing Features Instead of User Needs

One of the most common mistakes is describing a technical solution rather than a user problem.

Teams frequently write stories about buttons, forms, APIs, databases, or system integrations. While these may be necessary components of delivery, they are not user needs.

A useful test is to ask, “Why does the user need this?” If the answer cannot be clearly articulated, the story may be solution-focused rather than user-focused.

Making Stories Too Large

Large stories create uncertainty and make delivery difficult to estimate.

Stories such as “Manage my account” or “Submit an application” often contain numerous journeys, decisions, and edge cases.

Breaking work into smaller, outcome-focused stories helps teams deliver incrementally, identify risks earlier, and gather feedback sooner.

Including Multiple User Needs in One Story

A story should represent a single coherent objective.

When a story attempts to satisfy multiple user groups or several distinct outcomes, discussions become complicated and acceptance criteria expand rapidly.

Smaller stories tend to generate clearer conversations and better delivery outcomes.

Treating User Stories as Requirements Documents

Some organisations attempt to capture every possible detail within the story itself.

The result is often lengthy documentation that nobody reads.

Stories should facilitate discussion rather than replace it. Supporting information can exist elsewhere, including service blueprints, process maps, designs, research findings, and technical documentation.

Writing Stories Without User Evidence

A story disconnected from user insight is merely an assumption.

This does not mean every story requires a dedicated research session. However, teams should understand what evidence supports the need and why the work matters.

When stories are linked directly to research findings, delivery decisions become easier to justify.

Using Generic User Labels

Stories frequently begin with phrases such as “As a user.”

While technically correct, they often provide little context.

Public services commonly support citizens, caseworkers, administrators, contact centre staff, policy teams, inspectors, and numerous other groups.

Being specific helps teams understand context, constraints, and priorities.

Writing Acceptance Criteria Too Late

Acceptance criteria are often added hurriedly before development begins.

This approach misses a valuable opportunity.

Acceptance criteria should emerge during story refinement conversations. Early discussion helps uncover assumptions, identify risks, and expose gaps before work starts.

Confusing Acceptance Criteria with Test Scripts

Acceptance criteria define what success looks like.

Test scripts explain how that success will be verified.

The distinction matters. Acceptance criteria should focus on outcomes and behaviour rather than step-by-step instructions.

Ignoring Non-Functional Requirements

Many stories focus exclusively on functionality while overlooking accessibility, performance, security, and usability.

In public sector delivery, these considerations are often essential rather than optional.

Accessibility requirements, for example, should not appear as an afterthought. They should be embedded within the team’s understanding of what good looks like.

Writing Stories in Isolation

The final pitfall is treating story writing as an individual activity.

Strong stories emerge through collaboration between analysts, designers, developers, testers, product managers, and stakeholders.

When diverse perspectives are involved early, gaps are identified sooner and shared understanding improves significantly.

Common Mistakes in Writing Acceptance Criteria

Acceptance criteria often determine whether a story succeeds or fails.

Even when the user story is strong, weak acceptance criteria can introduce ambiguity that creates problems throughout delivery.

One frequent mistake is writing criteria that are too vague.

Statements such as “The system should work correctly” or “The user should be able to access the service” provide little guidance. Different people may interpret them in different ways.

Effective acceptance criteria are specific and observable.

For example:

“Given a citizen has completed all mandatory fields, when they select Submit, then the application is successfully received and a confirmation message is displayed.”

This describes behaviour that can be understood, developed, and tested.

Another common issue is focusing exclusively on happy paths.

Real services contain errors, exceptions, validation rules, incomplete information, and unusual user behaviour. Acceptance criteria should help teams think through these scenarios.

A citizen may lose internet connectivity midway through an application. A user may enter invalid data. A caseworker may lack appropriate permissions. These situations should be considered where relevant.

Teams also sometimes create excessively detailed acceptance criteria.

When dozens of criteria are attached to a single story, it is often a sign that the story itself should be split. Acceptance criteria should clarify scope, not compensate for overly large stories.

The most effective criteria strike a balance. They provide enough detail to remove ambiguity while remaining concise and outcome-focused.

Ensuring Stories Support Delivery and User Needs

User stories serve two purposes simultaneously.

They help teams understand user needs, and they help delivery teams organise work.

Problems occur when one objective is prioritised at the expense of the other.

Stories that focus solely on delivery efficiency can become technical tasks with little connection to service outcomes. Conversely, stories that focus only on user needs may lack sufficient clarity for implementation.

Business analysts and service designers sit at the intersection of these concerns.

Their role is often to translate service understanding into delivery-ready work without losing sight of the user.

One useful approach is to continually connect stories back to the wider service.

How does this story support the end-to-end journey?

What problem is it solving?

What evidence demonstrates its value?

What happens if it is not delivered?

These questions help teams avoid building isolated features that contribute little to the overall service experience.

Service mapping, journey mapping, and service blueprints can be particularly valuable here. They provide context that individual stories cannot capture on their own.

Stories should be viewed as part of a larger narrative rather than standalone requirements.

When teams understand where a story sits within the broader service ecosystem, delivery decisions become more informed and prioritisation becomes easier.

Final Thoughts

Writing better user stories and acceptance criteria is not about following a template perfectly.

It is about creating shared understanding.

The most effective stories help multidisciplinary teams understand who they are serving, what problem they are solving, and what successful delivery looks like. The most effective acceptance criteria remove ambiguity without restricting collaboration or innovation.

In public sector delivery, where services often involve multiple organisations, complex policies, and diverse user groups, this clarity becomes even more important.

A well-written story will not guarantee successful delivery. However, poorly written stories almost guarantee confusion, rework, and wasted effort.

Perhaps the most useful question teams can ask during refinement is a simple one:

“If someone entirely new joined the team tomorrow, would they understand the user need, the expected outcome, and how success will be measured from this story alone?”

If the answer is no, there is probably more work to do.

What practices have made the biggest difference to the quality of user stories and acceptance criteria in your organisation?