The product owner has added a story to the sprint backlog.
“As a sales representative, I want to capture customer information so that I can manage my opportunities effectively.”
The team reads it during refinement. Everyone nods. It sounds reasonable, the business need appears straightforward, and the story is estimated at three points.
Development begins.
A few days later, the questions start.
Which customer information must be captured? Is the customer already expected to exist in the system? Can a representative create a customer while creating an opportunity? Which fields are mandatory? What happens if the customer record already exists? Does the same rule apply to existing opportunities?
The developer asks the business analyst. The business analyst asks the product owner. The product owner checks with sales operations.
The story that looked ready for development has become a chain of clarifications.
The problem is not that the team failed to write a user story. It is that the story was treated as a complete requirement when it was only a starting point for a conversation.
A user story is not the entire requirement
A common user story format is:
As a [user], I want [capability], so that [business benefit].
This format helps the team understand who needs something, what they need and why it matters.
But it does not automatically explain the rules governing that capability.
Consider the sales representative story. It identifies the user and the broad intention, but it does not define what customer information is required, how duplicates are handled or when the capability should be available.
That is not necessarily a flaw in the format. A user story is intended to express a need concisely and support further discussion. The mistake is assuming that the sentence alone provides enough detail for implementation.
A useful backlog item usually needs several connected elements:
A clear user need and business outcome.
Acceptance criteria that define observable, testable behaviour.
Relevant business rules, constraints and dependencies.
Examples or supporting designs where they help clarify the requirement.
Agreement on what is included and what remains outside the scope.
The amount of detail should reflect the story's complexity, risk and proximity to development. A straightforward change may need little supporting documentation. A regulatory workflow or financial calculation may require substantially more.
The objective is not to make every story long. It is to make the intended behaviour clear enough for the team to build and verify it.
Start with the outcome, not the screen
Suppose a sales manager asks for a mandatory field called “Qualification Status” on every opportunity.
A literal interpretation would produce a simple requirement: add the field and prevent users from saving without a value.
Before writing the story, the analyst should ask why the field is needed.
Perhaps management wants to distinguish qualified opportunities from early-stage leads. Perhaps representatives are advancing opportunities without completing discovery. Or perhaps the reporting team needs a consistent way to calculate pipeline quality.
These problems may lead to different solutions.
If the objective is consistent qualification, adding a field may not be enough. The team may also need to define the qualification values, establish when each value should be selected and decide whether progression through certain stages should depend on that information.
The story should reflect the business outcome, not merely reproduce the requested design.
For example:
“As a sales representative, I want to record the qualification status of an opportunity so that I can maintain an accurate pipeline and help managers assess opportunity readiness.”
This is a better starting point. It connects the requested capability to a meaningful business purpose.
It is still incomplete, however. The team must agree on what the qualification status means and how the system should behave.
Write acceptance criteria that can be tested
Acceptance criteria describe the conditions that must be satisfied for a story to be considered complete from the business perspective.
They should remove ambiguity without dictating unnecessary technical implementation details.
For the qualification-status story, consider these example criteria:
1. Recording a status
When a sales representative creates or updates an opportunity, the representative can select one of the approved qualification statuses.
2. Required information
When an opportunity reaches a defined qualification stage, a qualification status must be recorded before the opportunity can progress.
3. Existing opportunities
Existing opportunities that do not yet have a qualification status must be handled according to an agreed migration or exception rule.
4. Reporting
The saved qualification status is available to authorised users in the agreed opportunity views and reports.
These criteria are more useful than “the field should work correctly” because they describe behaviour that can be reviewed and tested.
Notice that the criteria also expose decisions that cannot safely be invented by the analyst. Which statuses are approved? At which stage does the field become mandatory? What happens to existing records? Which reports require the information?
Those are business decisions. The analyst should identify them, obtain the necessary agreement and document the result.
When to use Given–When–Then
For behaviour involving a specific condition and outcome, the Given–When–Then format can make acceptance criteria more precise.
Given an opportunity has reached the qualification stage and has no qualification status.
When the representative attempts to move it to the next stage.
Then the system prevents progression and explains that a qualification status is required.
This structure helps developers and testers see the starting conditions, the action and the expected result.
It is particularly useful for validation rules, permissions, calculations, workflow transitions and exception handling.
Not every criterion needs this format. A short list of clear conditions may be easier to read for simple stories. Use the format when it improves precision, not merely because a template requires it.
The questions that prevent rework
Good acceptance criteria often emerge from questions that the original request does not answer.
For the qualification-status example, an analyst should explore at least four areas.
Business rules: What are the permitted statuses? Can a status be changed later? Are some transitions restricted?
Exceptions: What happens when a representative cannot complete qualification because the customer has not provided the information? Is an exception permitted, and who can authorise it?
Permissions: Can every sales representative edit the status? Can managers override it? Are there differences between roles or business units?
Data and reporting: Does the status need to be available historically? What happens to existing records? Which reports depend on it?
The answers will vary by organisation. The important point is to uncover the decisions that materially affect the expected behaviour before the team builds the wrong thing.
You do not need to investigate every theoretical edge case in advance. Prioritise questions that affect business outcomes, compliance, data integrity, security, user experience or substantial rework.
Avoid two common mistakes
Mistake 1: Writing vague acceptance criteria
Consider this criterion:
“The system should validate the opportunity correctly.”
What does “correctly” mean? Which conditions should trigger validation? What message should appear? Can the user recover without losing entered information?
The criterion gives the team almost no testable information.
A more useful version would state the specific condition, expected behaviour and relevant exception.
For example:
“When a representative attempts to advance an opportunity to the qualification stage without selecting a qualification status, the system prevents the stage change and displays a message identifying the missing information.”
Now the behaviour can be demonstrated and verified.
Mistake 2: Turning acceptance criteria into a technical design
The opposite problem is prescribing the implementation too early.
A criterion such as “create a new database table, add three backend services and use a particular API endpoint” may constrain the development team without expressing the business requirement.
Technical constraints are sometimes necessary, particularly when an architecture, integration standard, security requirement or regulatory control has already been established. In those cases, document the constraint explicitly.
Otherwise, describe the required behaviour and let the technical team determine an appropriate implementation.
A good requirement is precise about what must happen, while leaving reasonable freedom over how it is achieved.
How detailed should a user story be?
A useful practical test is whether the team can discuss, estimate, implement and verify the story without repeatedly returning to the same unresolved business questions.
That does not mean every question must be answered before development. Some uncertainty is unavoidable, and Agile teams learn through delivery. The important distinction is between uncertainty the team has consciously accepted and ambiguity nobody has recognised.
For a small user-interface adjustment, a concise story and a few criteria may be enough.
For a workflow involving financial approvals, customer data, multiple roles and audit requirements, the story may need additional business rules, process diagrams, examples, permission scenarios and exception paths.
The right level of detail depends on:
The consequences of an incorrect interpretation.
The complexity of the business rules.
The number of systems and teams involved.
The maturity of the team's shared understanding.
The amount of uncertainty that can safely be resolved during development.
Do not measure requirement quality by the number of words, criteria or documents produced. Measure it by how well the requirement communicates the intended outcome and supports a reliable implementation.
A practical review before moving a story into development
Before marking a story ready, ask:
Is the user or business need clear?
Is the expected business outcome understood?
Are the acceptance criteria observable and testable?
Have the important business rules and exceptions been identified?
Are dependencies, permissions and data implications understood where relevant?
Can the product owner, developer and tester explain the intended behaviour consistently?
Are any unresolved questions explicitly recorded, with an owner and a plan to resolve them?
If the team cannot answer these questions, the story may need further refinement. That does not automatically mean it should be rejected from the sprint; urgency, risk and the team's delivery approach also matter. It means the team should make an informed decision about whether the remaining uncertainty is acceptable.
The real purpose of a good user story
A well-written user story is not a miniature specification designed to eliminate every conversation. It is a shared understanding of a user need, supported by enough detail to make meaningful progress.
Acceptance criteria turn that understanding into observable outcomes. Business rules clarify the decisions that govern those outcomes. Examples and models help where words alone are insufficient.
When these elements work together, developers have a clearer implementation target, testers have a basis for verification, product owners have a way to assess whether the intended value has been delivered, and business stakeholders have fewer surprises at the end.
The goal is not to write perfect stories.
It is to discover ambiguity early enough that resolving it is cheaper than correcting it after delivery.
Before you mark the next story as ready, do not just ask whether it is written. Ask whether the team understands what success will look like.
More practical perspectives on business analysis, product thinking and technology delivery are available in The Notebook on PushPullBuild.
