A user story template you can copy, with the acceptance criteria already filled in.

What a user story is, and what the acceptance criteria add

A user story names who wants something, what they want, and why. The classic form is one sentence: as a role, I want a goal, so that a benefit. It is deliberately short, because its job is to hold a place for a conversation rather than to replace one.

The acceptance criteria are what make the story testable. They state, as a list of things that are either true or false when the work is done, what the team agreed the story means. A story without them is an intention; a story with them is a shared definition of done that a reviewer can check without asking the author what they meant.

The difference between the two is a division of labour, not a difference in importance. The story holds the intent and stays negotiable: it is written to be argued with. The criteria record what the argument concluded, and they stop being negotiable once the work starts. If you find yourself adding detail to the story sentence, you are almost always writing a criterion in the wrong place.

The two common formats for criteria are Given/When/Then, which describes behaviour as scenarios, and a rule checklist, which lists constraints. Scenarios suit anything with a flow. A checklist suits anything with rules, like validation or permissions. Three to five criteria per story is typical; a story that needs twelve is usually two stories.

Which user story format to use when

Pick the format by what the criteria have to describe, not by what the team calls itself. A scrum user story template and an agile user story template are the same artifact: the Connextra sentence plus criteria. What actually changes between backlog items is whether the behaviour branches, and that is what the five tabs above differ on.

If the behaviour depends on state, write Given/When/Then, because whoever automates the test will otherwise write it for you and guess. If the work is a set of constraints, a rule checklist reads faster and is easier to review line by line. If you are still in discovery and do not know who the user is yet, a job story lets you write the situation down without inventing a persona to hang it on.

One rule holds across all five: copy the format, then fill it in before you share it. An empty skeleton pasted into a ticket is worth less than no ticket, because it looks like a decision was made.

User story examples with acceptance criteria you can copy

Below are sixteen user stories drawn from eight parts of a product, two from each, with the acceptance criteria written out beside every one. Each story carries between three and five criteria, and every criterion names a number, an exact state or an exact action, so a tester can pass or fail it without asking what was meant. Copy them as they are, then swap the role and the numbers for your own.

Onboarding. As an IT administrator standing up a workspace for 240 staff across 6 sites, I want a setup checklist that shows which of the 7 required steps are still open, so that I hand over a workspace that is configured rather than one that looks configured. Done when: the checklist lists all 7 steps, each marked done or not done; every open step links straight to the screen that completes it; the workspace cannot be switched to live while any required step is open; completing a step updates the checklist without a page reload; the audit log records who completed each step and when.

Onboarding. As a newly hired claims adjuster working my first 20 cases, I want the 8 steps of the claim workflow shown on the case itself, so that I stop asking a colleague what comes next. Done when: each case displays the 8 steps with the completed ones marked; the case header names the next step by its exact title; skipping a step requires choosing a reason from the list before the case can move on; the checklist switches itself off after the adjuster closes 25 cases and can be switched back on from their profile.

Billing. As a finance manager closing the month for 12 legal entities, I want to download one consolidated invoice per entity rather than per subscription, so that I can file them without merging PDFs by hand. Done when: each entity produces exactly one PDF covering every subscription billed in that period; the file name carries the entity name and the billing month; entities with no charges produce no file rather than an empty one; the download completes for 12 entities in a single request.

Billing. As the office manager of a dental practice with 18 seats, I want to add 4 seats halfway through a billing period and see the prorated amount before I confirm, so that I am not surprised by the next invoice. Done when: the prorated amount is shown before confirmation and matches the amount charged to the cent; all 4 seats are usable immediately after confirmation; the next invoice carries the proration as its own line with the date range it covers; an attempt to reduce the seat count below the number of seats in use is refused, and the message states how many seats must be freed first.

Search and filtering. As a recruiter working a pipeline of 12,000 candidate profiles, I want to search by skill and by last-contacted date in the same query, so that I stop exporting to a spreadsheet to combine them. Done when: results satisfy both conditions at once, not either one; a name misspelled by a single character still returns the matching profile; archived profiles are excluded unless the recruiter includes them explicitly; the result count is exact up to 10,000 and shown as "10,000+" above that; a query with no results names both active conditions and offers to drop one.

Search and filtering. As a logistics dispatcher who rebuilds the same view of late shipments every morning, I want to save that filter under a name and open it from the sidebar, so that I stop setting 6 conditions by hand each day. Done when: the saved filter stores all 6 conditions, including relative dates such as "today"; opening it runs the query against current data rather than showing the result set from last time; a filter shared with the team is read only for everyone except its owner, who can be seen by name; deleting a filter that 3 other people have opened in the last 30 days warns with that count before it is removed.

Notifications. As a school administrator copied on every facilities request across 4 campuses, I want one daily digest instead of a message per request, so that I read 1 email in the morning rather than 60 through the day. Done when: the digest sends once per day at the hour the administrator selects; requests are grouped under the campus they came from; a day with no new requests sends nothing at all; each line shows the request title and its current status and links to the request; switching from daily to weekly takes effect at the next send and carries over the items already queued.

Notifications. As an account manager copied on a renewal thread that has run to 40 replies, I want to mute that one thread without muting the account, so that I keep my alerts for the other 22 accounts I own. Done when: muting silences that thread only, and notifications for the other 22 accounts continue; a direct mention inside the muted thread still notifies once; the muted marker is visible to the person who muted it and to nobody else; unmuting resumes notifications from that point and does not replay the messages posted while it was muted.

Admin and permissions. As a compliance officer at a credit union, I want an auditor role that can open every case record and change none of them, so that an external reviewer can work without a supervised screen share. Done when: an account holding the auditor role can open all 9 record types and sees no save, delete or assign control anywhere; an API token issued to that role is refused with a 403 on every write endpoint; the role can still export records to CSV; granting the role requires an existing administrator and writes both names and a timestamp to the audit log.

Admin and permissions. As an HR operations coordinator processing 15 leavers a month, I want a single action that revokes a departing employee's access while keeping the records they created, so that offboarding does not erase four years of history. Done when: revoking access ends every active session for that account within 60 seconds; the leaver's name stays on the records they created and is shown as inactive; any open tasks assigned to them are listed for reassignment before the revocation finishes; a revoked account cannot be reactivated except by an administrator, and the reactivation is logged.

Reporting. As a data analyst pulling 18 months of ticket history into a warehouse, I want an export that returns every matching row rather than the 1,000 shown on screen, so that my totals reconcile with the product. Done when: the export contains all matching rows, verified against a query returning 250,000; column headers match the field names used by the API; timestamps are written in ISO 8601 with the UTC offset; an export above 100,000 rows is prepared in the background and the analyst is told where to collect it; an export that fails reports the row number it stopped at.

Reporting. As a nonprofit program director presenting to a board of 7 trustees, I want a dashboard of 4 numbers that each state the period they cover, so that nobody spends the meeting asking what the figure means. Done when: each of the 4 numbers displays its date range next to it; clicking a number opens the list of records it was calculated from; the page shows the time of the last refresh and that time is never more than 1 hour old; a metric with no underlying records reads "no data for this period" instead of 0.

Integrations. As a marketing operations manager who inherited a second CRM through an acquisition, I want both systems connected at once rather than one replacing the other, so that neither team loses their pipeline during the merge. Done when: both connections remain active at the same time and each displays the account it authenticates as; every imported record is tagged with the system it came from; a field written by one connection is not overwritten by the other, and the clash is listed for a human to resolve; disconnecting one system leaves the records already imported from it in place.

Integrations. As a payroll specialist running a nightly sync of 1,400 employee records, I want a run that fails partway to tell me exactly what did not land, so that I fix 12 records instead of rerunning all 1,400. Done when: the run reports counts for records written, skipped and failed; each failed record is listed with its employee identifier and the reason it failed; rerunning the sync processes only the failed records; one alert is sent for the run, not one per failed record; a record either updates on every field or on none, never on some.

Mobile. As a field technician writing job notes at the top of a ladder with one hand, I want every control I need inside the bottom third of the screen, so that I am not stretching my thumb across the display on a rung. Done when: the controls required to complete a job sit in the bottom third at screen widths from 360 to 430 points; notes persist as typed and survive the app sitting in the background for 30 minutes; a job can be closed in 3 taps from the job screen; a quantity field opens the numeric keypad rather than the full keyboard.

Mobile. As a warehouse supervisor counting stock in a freezer aisle with no signal, I want counts saved on the device and uploaded later, so that a lost connection does not cost me a 2 hour count. Done when: counts entered offline are stored on the device and shown as pending; the count screen states how many entries are waiting to upload; entries upload on their own when the connection returns and change from pending to saved; two supervisors counting the same location offline produce two entries, both kept and flagged, with neither overwriting the other; the device holds at least 500 pending entries before it refuses a new one.

INVEST: the six-part check on a story before it enters a sprint

INVEST is a checklist coined by Bill Wake in 2003, and it is still the shortest useful test of a user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Read the story once against each letter. A story that fails one of the six is not a bad story, it is a story that needs one more conversation before anyone estimates it.

Independent means it could ship without waiting on another story. Negotiable means it leaves room to discuss how, so a story that names a dropdown and a database column is a solution wearing a story's clothes. Valuable means the person in the sentence would notice if it shipped. Estimable means the team knows enough to size it. Small means it fits comfortably inside one sprint. Testable means every criterion can be checked without asking the author what they meant.

Two of the six fail far more often than the rest. Small fails because a story was written at the size of a feature, and the fix is to split it along the acceptance criteria you already wrote: each criterion that could be released on its own is a candidate story. Testable fails because the criteria carry adjectives instead of numbers, and the fix is mechanical, which is why the builder on this page flags them.

INVEST is a prompt, not a gate. Nobody should be blocked on Negotiable. The value is that six words catch, in about thirty seconds, the two failures that otherwise surface halfway through a sprint.

The part a template cannot fill in: who actually asked

A template gives you the shape of a story. It cannot tell you whether anybody wants it. The sentence "as a support lead, I want to filter the board by plan" is well formed whether it came from 30 customers or from one person in a planning meeting, and the format hides the difference completely.

That is why the first line of a good story names a real person at a real scale. A role written as "a support lead triaging 200 tickets a week" is falsifiable: either you have that person or you do not. A role written as "a user" is not, and it is how backlogs fill with work that nobody asked for and nobody misses.

The practical obstacle is that the evidence is scattered. It sits in support tickets, in sales-call notes, in a Slack channel somebody muted, and in a survey export nobody reopened. Most teams write the story from memory because reconstructing where the request came from costs an afternoon, not because they think the provenance does not matter.

That is the step Sleekplan removes. Requests arrive from the widget, the portal and your support tools onto one board, where they are voted on and grouped. The story is written as a document in the same workspace, linked to every request it came from, so a reviewer can click from the acceptance criteria back to the person who asked and read what they actually said.