User Story Acceptance Criteria Examples to Reduce Rework
Write acceptance criteria that cut rework
If you’ve ever shipped a “done” story only to see it bounce back with bugs or gaps, your criteria were probably too loose. This guide puts user story acceptance criteria examples front and centre so you can write clear, testable statements that remove guesswork for developers, QA, and stakeholders.
We focus on practical phrasing for real handoffs: choosing a structure that fits the story, covering negative paths and edge cases, and capturing non-functional essentials without bloating the ticket. You’ll see how to turn fuzzy intentions into concrete outcomes that two different testers could verify the same way.
By the end, you’ll know how to select a criteria format, avoid ambiguity traps, and produce acceptance criteria that reduce rework, speed up sign-off, and make delivery feel smoother for the whole team.
Why rework happens on seemingly simple stories
Most rework comes from ambiguity: different people interpret the same sentence in different ways. When states, boundaries, or outcomes are implied rather than written, teams fill the gaps with assumptions. Small gaps compound across UI, error handling, data rules, and performance expectations.
Typical ambiguity you can remove upfront
- Who can do what: missing roles, permissions, or visibility rules.
- What exactly appears: copy, formats, defaults, and error messages.
- Edge and negative paths: timeouts, invalid inputs, empty states, retries.
- Non-functional expectations: performance, accessibility, resilience, audit.
- Handoff artefacts: test data, links to designs, tracking requirements.
Key insight: Acceptance criteria are a shared mini test plan. If two people can run them and reach the same result, they’re specific enough.
Choose a structure your team can test
Scenario (Given–When–Then)
Best for stateful flows and visible behaviour. Keeps each scenario tight and outcome-focused.
- Use when there’s a clear trigger and a user-visible result.
- Write one scenario per path; add separate scenarios for errors.
- Keep each Then verifiable (UI change, redirect, message, saved state).
- Example: Given an account is locked, when the user tries to sign in, then a lock message is shown and no session is created.
Rules + Examples
Best for business rules, calculations, and validations where combinations matter.
- List atomic rules, then add concrete examples (including edge cases).
- Document precedence if rules can clash.
- Example: A discount applies only if the basket total meets the threshold and the code is not expired; include examples at, below, and above the threshold.
Pick one structure per story. Mixing structures mid-story blurs test coverage and confuses sign-off.
Practical user story acceptance criteria examples
Login with email and password
- Valid credentials create a session and take the user to the agreed landing page.
- Invalid credentials show a generic error without revealing which field is wrong.
- Email accepts mixed case and trims leading/trailing spaces.
- Account lockout applies after repeated failed attempts, as defined by the security policy.
- Error messages are announced to assistive technologies and associated with the relevant inputs.
Include the supported browser and device list in the ticket link or meta so QA knows where to verify.
Password reset via email link
- Submitting a registered email sends a reset link; the UI response is the same for registered and unregistered emails.
- Reset links expire after the agreed timeframe and can be used once.
- New passwords must meet the documented policy; unmet rules are listed inline.
- Successful reset shows confirmation and allows sign-in with the new password; the old password no longer works.
Search with filters
- Results reflect the intersection of all selected filters and the query term.
- No-results state shows a helpful message and a clear way to reset filters.
- Selected filters persist when paginating and after navigating back from a result.
- Special characters in queries are handled safely; attempted injection is blocked and logged.
- Sort order and default page size follow the documented specification.
File upload
- Only the allowed file types are accepted; others show a clear validation message.
- Files exceeding the maximum size are blocked with an explanation.
- Users see progress and a final success or failure state; failed uploads do not create partial records.
- Uploaded files are virus-scanned and stored in the approved location with sanitised filenames.
- Network interruption offers a user-facing recovery path (retry or restart) where supported.
Audit log entry for profile changes
- Each change records who made the change, when, and which fields changed.
- Before and after values are captured for auditable fields; sensitive values are masked according to policy.
- Entries are immutable and include a consistent timezone.
- Viewing the log is restricted to authorised roles.
Non-functional acceptance: performance and accessibility
- Key pages meet the team’s agreed performance thresholds under typical load.
- Essential flows meet the agreed accessibility standard (for example, WCAG 2.1 AA) with focus order, labels, and contrast addressed.
- Works on the supported browsers and screen sizes listed in the support matrix.
- Errors are logged with enough context to diagnose (including a correlation ID).
- No sensitive details are leaked in error messages or logs.
Spot the difference: vague vs clear criteria
Vague
- Search should be fast and accurate.
- Show helpful errors.
- Support all browsers.
Clear
- Search returns items matching all active filters and the query; no-results state provides a reset option.
- Validation messages use agreed copy and are linked to fields for assistive tech.
- Verified on the supported browser list; any deviations are documented with workarounds.
Definition of Done add-ons for smooth handoff
- Test data or accounts included (e.g., a locked user, an admin user).
- Copy and empty-state messages finalised or linked to the source of truth.
- Tracking/analytics requirements listed with the exact event names and triggers.
- Accessibility notes included for interactive elements and error states.
- Non-functional thresholds and environments for testing are specified.
- Rollback behaviour or safe failure state is described.
Mistakes to avoid and sensible trade-offs
Mistakes to avoid
- Bundling multiple flows into one long scenario.
- Writing outcomes that can’t be observed by QA.
- Leaving security and accessibility to “later”.
- Copying criteria from another story without re-checking the rules.
Trade-offs to manage
- Detail vs speed: keep criteria short but cover decision points and states.
- UI vs system focus: include what QA can see and what must happen behind the scenes.
- One story vs many: split when paths or rules diverge to keep criteria crisp.
Final advice
Start with the user outcome, choose Scenario or Rules as your backbone, then list the smallest set of verifiable checks that prove success, failure, and boundaries. Include the non-functional basics and handoff meta so QA can run the same steps you imagined. Do this consistently and your acceptance criteria will act like a reliable contract that reduces rework and speeds up delivery.
Turn what you just learned into a real IT career move
Whether you want to build job-ready skills, follow a structured career path, or get expert advice before choosing a course, Codionix IT Training UK can help you move forward with confidence.
Explore IT Courses
Browse instructor-led training across cloud, cybersecurity, networking, data, support, digital skills, and more.
View CoursesView Career Paths
See structured pathways designed to help you progress toward roles like helpdesk technician, network engineer, ethical hacker, and beyond.
Explore Career PathsBook Free Consultation
Not sure which course or path fits you best? Speak with the team and get clear, practical guidance before you commit.
Get Free AdviceRelated articles
Project handover checklist IT support UK
A practical, UK-ready handover checklist mapped to ITIL roles and SME SLAs. Learn how to prevent post-go-live chaos with clear acceptance criteria and knowledge-base guidance.
PRINCE2 vs AgilePM UK: A Practical Guide for Your First IT Project Role
A practical decision guide for UK beginners and career changers navigating their first IT project role. Compare PRINCE2 and AgilePM with real-world scenarios and flexible learning options.
Lightweight risk management for small IT projects: a plan
A practical, lightweight approach to risk management tailored for small IT projects. This guide shows quick identification prompts, simple likelihood/impact checks, and a portable risk log you can maintain without bureaucracy.
Free IT Training Consultation
Use the calendar to book your free one-to-one course advice session with a Codionix IT training expert. Get personalized career guidance to help you choose the best online IT course in the UK for your goals. We’re happy to answer any questions you may have and help you determine which of our training programs best fit your needs.
How it works?
You schedule a call at your convenience
We do a free discovery and consulting meeting
We guide you towards the best career path for you
Your benefits:
- Personal Guidance
- Course Clarity
- Career Focus
- Honest Advice
- Stress-Free
- Clear Direction
Find us on:
Schedule a Free Consultation
Not sure which IT course is right for you? Book a free consultation and get expert guidance from our team — no cost, no pressure.
