They are the item-specific counterpart to the Definition of Done, which asks did we build it well. Not a Scrum term. Completely universal in practice.
The four-part test
Apply this to every criterion, out loud, in the room. It takes seconds and it removes most of what would otherwise cause an argument three weeks later.
- Binary — it passes or it fails
- Observable — somebody other than the author can check it without reading the code
- Free of implementation detail — says what must be true, not how to build it
- Necessary — if the feature would still be acceptable without it, it isn't one
The form is user-friendly.— an aspiration, not a criterion.
Password is hashed before storage.— that's a Definition of Done item.
The user cannot submit a password under eight characters.
Twelve criteria for one story
This is US1.1 — new user account registration — from Epic E01. Twelve felt excessive when the team wrote them. They meant a developer never had to guess what an error state should do.
- Core functionality
- AC1 — User can access the registration screen from the main welcome page.
- AC2 — Registration form includes mandatory fields: Email, Password, Confirm Password, First Name, Last Name.
- Terms and conditions
- AC3 — Users can view Terms & Conditions and Privacy Policy via links.
- AC4 — Agreement via a mandatory checkbox is required for submission.
- Validation and security
- AC5 — Email format validation ensures it contains "@" and a domain.
- AC6 — Password meets complexity requirements: minimum 8 characters, at least one uppercase, one lowercase, one number.
- AC7 — Password confirmation must match the original entry.
- Error handling
- AC8 — Clear, user-friendly error messages appear beside fields on validation failure or empty mandatory fields.
- AC9 — If the email is already registered: "This email is already registered. Please log in or use a different email."
- Successful submission
- AC10 — A new user account is created in the system.
- AC11 — On-screen success message: "Registration Successful! Please check your email to verify your account."
- AC12 — User is redirected to a "Verify Your Email" screen.
The twelfth one
AC12 commits the team to a screen. That screen needs a verification email, a token, an expiry and a resend path.
None of it existed anywhere in the backlog. Epic E01 held three stories — registration, login, profile personalisation. Not one of them was email verification.
You are already thinking your team would have caught that.
This one did catch it — in this session, three chapters before it mattered. They discussed it, agreed it was a problem, left the criterion as written, and took the item into the Sprint anyway.
Catching it was never the problem. It failed the Definition of Ready on the open-dependency line, went in regardless, and surfaced at the Sprint Review. What that cost is in chapter 1, free to read.
Two legitimate fixes were available. Write a story for email verification and prioritise it properly, or narrow AC12 to what US1.1 actually delivers. They did neither.
The second thing this session got wrong
Look at AC2 again. The story asks for three things — email, password, terms. AC2 lists five: Email, Password, Confirm Password, First Name, Last Name.
The story grew during the criteria session and nobody said a word about it. Two extra mandatory fields is more UI, more validation, more test cases — and it arrived without anyone deciding anything.
That is what scope creep genuinely looks like. It isn't somebody storming in and demanding a new feature. It's a list getting longer while everyone nods.
Personalisation mattered to Beauty Spot, so the extra names are defensible. The correct move was to say so out loud, update the story, and have the Product Owner confirm it still passes Small. Thirty seconds of work. Nobody did it.
The INVEST check that preceded it
Every story gets this before anybody writes a criterion. It is worth reproducing in full, because two of the six answers are qualified rather than clean — and that is the normal case, not a failing.
The story itself: as a new BCA user, I want to register by providing my email, password, and agreeing to terms, so that I can create my secure BCA profile and access platform features. One of three stories sliced from Epic E01.
| Independent | Yes, with a caveat. Login cannot be delivered without this — you cannot log in to an account that cannot be created. Sequential rather than entangled. |
| Negotiable | Yes. The goal is fixed; password rules and the post-registration flow remain open. |
| Valuable | Yes. Enables user acquisition, which every later feature depends on. |
| Estimable | Yes. Scope is defined by the criteria. |
| Small | Reviewed as yes — and not re-checked after AC2 grew. See above. |
| Testable | Yes. Each criterion is binary and observable. |
A clean row of six ticks usually means somebody wasn't looking. Independent is rarely absolute, and Small stops being true the moment criteria get added.
Technical notes the session produced
- Backend — POST /api/register, developed as part of this story.
- Frontend — registration screen, client-side validation, integration with the API.
- Database — Users table schema finalised, password stored hashed.
Note that the hashing sits here rather than in the criteria. It's a quality standard that applies to every story, which makes it a Definition of Done item.
Where this sits
Criteria are the last thing written before an item can be Ready. They come after the story, which comes after the Epic, which comes after the capability area. If a criterion cannot be traced back up that chain, it is worth asking who asked for it.