Acceptance criteria: the acceptance test plan per story
In agile, each user story carries its acceptance criteria: the precise conditions that say it is done and compliant. These are the acceptance test plan's test cases, but written when the story is written, not after. The Given/When/Then format helps: given a cart with one item, when I remove that item, then the cart is empty and shows a message. It is verifiable, unambiguous, and it serves the developer, the tester and the product owner who signs off, all at once.
Acceptance happens every sprint, not at the end
Agile's big benefit is killing the tunnel effect. Rather than a single acceptance phase at project end, where all bugs surface at once too late, you validate stories at the end of each sprint, during the review. The product owner accepts or rejects each story against its acceptance criteria. A rejected story goes back to the backlog. So quality is checked in small batches, continuously, and a defect is found while it still costs little to fix.
The Definition of Done, the distributed sign-off
The Definition of Done is the list of conditions a story must meet to count as finished, beyond its own criteria: code reviewed, tests passing, responsive checked, accessibility verified, documentation up to date. It is the equivalent of the acceptance sign-off, but applied to each story rather than the whole project. A cross-cutting checklist like our acceptance template feeds the Definition of Done directly: you pull from it the checks that must hold for every delivered story.
Definition of Ready vs Definition of Done, do not confuse them
Two checklists frame a story, at two different moments. The Definition of Ready says when a story is ready to enter a sprint: clear need, acceptance criteria written, mockup available, dependencies cleared, story small enough to fit the sprint. The Definition of Done says when it is finished: built, tested, reviewed, compliant with its criteria. The first protects the sprint's entrance, the second protects its exit. Confusing the two is the classic mistake: you pull in a fuzzy story because the Definition of Ready was sloppy, then declare it finished without really verifying it because the Definition of Done is just as sloppy. On the acceptance side, a serious Definition of Ready avoids mid-sprint round-trips, and a Definition of Done that holds avoids shipping the almost-finished work the client will send back next sprint.
Defect tracking stays the crux
Agile or not, a bug found in a sprint review must become a tracked ticket, not a spoken remark that evaporates. The difference is the cadence: defects enter the backlog and are prioritized in the next sprint, or fixed within the sprint if they block. A visual feedback tool that captures technical context stays valuable, especially when the product owner or a client tests a demo: they click the issue, the ticket leaves reproducible, and it lands where the team already prioritizes its work.
Frequently asked questions
Does agile really remove the acceptance test plan?
No, it breaks it down. The rigor stays the same (a verifiable expected result, a clear status), but instead of a frozen document signed off at project end, it lives in the acceptance criteria of each story and in the Definition of Done. On projects with a strong contractual requirement, you often also keep a lighter final overall acceptance to record delivery.
Acceptance criteria vs Definition of Done, what is the difference?
Acceptance criteria are specific to a story: they describe what that particular feature must do. The Definition of Done is cross-cutting: it is the quality standard common to all stories (tests, code review, responsive, accessibility). A story is done when it meets both its own acceptance criteria and the team's Definition of Done.
Who signs off on acceptance in agile?
The product owner owns story acceptance during the sprint review, on behalf of the business or the client. On client projects, the client themselves often tests end-of-sprint demos and reports what is wrong. The development team stays responsible for the Definition of Done. It is a shared, continuous control, where classic-cycle acceptance concentrates validation in a single final phase.
Who creates the Definition of Done?
The development team, collectively, not the product owner alone. It is a standard the team sets for itself and keeps up to date: it reflects what they consider necessary for a story to be truly shippable. The scrum master facilitates, the team decides. A Definition of Done imposed from above and never revisited becomes an ignored formality; one written and revised by the people doing the work stays alive and respected. Revisit it at each retrospective: whatever cost you time in acceptance deserves a place in it.