Deliverable Acceptance Criteria: How to Write Them

Deliverable acceptance criteria are the pass/fail conditions a piece of work must meet before the client accepts it. Write them before production starts, make each one measurable, name who decides, and record the outcome. Do that and “done” stops being a matter of opinion. Below you’ll find what good criteria look like, examples for creative and video work, a template, and a way to document sign-off.

TL;DR

• Acceptance criteria are pre-agreed conditions a deliverable must meet, written from the accepting party’s point of view, not the maker’s.
• Each criterion should be clear, testable and pass/fail. Describe what the result must be, not how you get there.
• Agree them before work begins, with the people who will accept, build and check the deliverable in the same conversation.
• Record the decision (accepted, accepted with conditions, or rejected) with a name and a date.
• For creative work, translate taste into observable specs: format, length, loudness, color space, captions, naming and delivery method.

Table of Contents

• What deliverable acceptance criteria mean
• Acceptance criteria vs. requirements, scope and user stories
• What makes a criterion good
• Examples for creative and production deliverables
• How to write them, step by step
• Verifying and documenting acceptance
• Common mistakes
• A reusable template
• Perspective
• Keep criteria, versions and approvals in one place
• FAQ
• Sources

What deliverable acceptance criteria mean

The Ohio Office of Budget and Management’s guidance describes acceptance criteria as the conditions a deliverable must meet to be accepted by a user, written as pre-established requirements from the user’s point of view. The Center for Project Innovation puts the same idea another way: they set the standard of “fit for purpose” for the people accepting the work, not what the deliverer thinks is good enough.

That last point matters most in production. Without criteria, acceptance is a mood. The editor believes the cut is finished, the client feels it is not, and the argument that follows has no reference point. With criteria, you compare the work against a list both sides already agreed to.

The term comes up constantly in software, where it sits beside user stories. But the logic applies to any project output: a campaign video, a localized subtitle file, a motion graphics package, a podcast master, a brand guide. A deliverable is anything you hand over. Criteria say what “handed over correctly” means.

Acceptance criteria vs. requirements, scope and user stories

These terms overlap, so it helps to separate them.

• Scope or requirements describe what the project will produce and why. They are broad.
• Acceptance criteria describe how you will judge each deliverable against those requirements. They are narrow and checkable.
• User stories are short statements of a need, usually “as a [role] I want [result] so that [benefit].” Acceptance criteria sit under a story and say when it is satisfied.

The Scrum Alliance notes that acceptance criteria focus on the “what” rather than the “how.” Its example is that users can pay with Google Pay or Apple Pay at checkout. It states the behavior the user needs and leaves the implementation to the team.

Creative equivalent: “The master is delivered as a ProRes 422 HQ file at 1920x1080, 23.976 fps” is a criterion. “Use the best export settings” is not, because nobody can fail it.

What makes a criterion good

Across the official and professional guidance, the same qualities keep appearing.

Clear and unambiguous. The Ohio guidance asks for simple statements with no ambiguity and an explicit line between what is and is not acceptable. If two reasonable people could read a criterion and disagree on whether it passed, rewrite it.

Measurable, with pass/fail. The same guidance says criteria tied to payment should be relevant to the deliverables and measurable as pass or fail. The Scrum Alliance adds that criteria should be concise and testable.

Observable. Wording like “looks professional” cannot be verified. Wording like “the lower third stays inside the title-safe area on every frame” can.

Relatively high level, yet useful. You do not need a hundred lines per deliverable. The Ohio guidance recommends keeping them high level while still useful. Podeswa, writing for InformIT, advises specifying enough criteria for the minimum functionality that delivers value the customer would view as significant.

Owned. Each criterion needs someone who can say yes. RN Digital’s checklist recommends naming the role that will accept the work, alongside the deliverable, the observable outcome, a measurable quality metric and the verification method.

Examples for creative and production deliverables

Published guidance leans heavily toward software, so here is how the same principles translate to media work. These are illustrative examples to adapt, not industry standards. Replace the numbers with your client’s actual specifications.

A 60-second brand video

Notice the last row. Subjective approval is still allowed. It is simply tied to a process: a defined number of review rounds, with notes logged and closed.

A translated subtitle package

• Subtitle files delivered for each agreed language, in the agreed file format.
• Every cue stays within the agreed character limit per line and two lines per cue.
• Timing is checked against the locked picture, with no cue overlapping the next.
• Names, brand terms and product names follow the supplied glossary.
• A native-speaker reviewer named in the brief signs off on each language.

A design asset set

• Every asset in the list is delivered at the sizes in the spec sheet.
• Source files are layered and organized, with fonts and linked images included or listed.
• Files follow the naming convention in the brief.
• Color values match the supplied palette.

Behavior-style criteria for interactive deliverables

When a deliverable is an interactive review page, a player or a delivery portal, Given/When/Then phrasing works well. For example: given a client with a review link, when they open the cut on a phone, then the video plays and they can leave a timestamped comment. Keep the “then” outcome verifiable from the outside, in observable terms, rather than tied to how it is built.

For campaign assets such as landing pages and articles, a content marketing checklist can supply the individual checks you then convert into pass/fail criteria before anything goes to the client.

How to write them, step by step

1. List the deliverables. One line per output. If you cannot name it, you cannot accept it. Our deliverables checklist is a good starting inventory.
2. Gather the right people. InformIT’s agile analysis guidance recommends working through criteria in collaborative sessions with business stakeholders, testers and developers, the “Triad.” In production, that means the client or producer, the creative lead and whoever will quality-check the file.
3. Draft three to eight criteria per deliverable. Cover format, content, quality, completeness and delivery method. More than that usually means you are specifying how, not what.
4. Make each one pass/fail. Add a number, a reference document, a sample or a named approver wherever a word is subjective.
5. Define the verification method. Say who checks, how, and against what. RN Digital recommends specifying the verification method and sample data, and using concrete test data with expected results so checks can be repeated and disputes avoided.
6. Agree them before work starts. A SaaS acceptance-testing article states criteria should be written before testing begins, not after, so the goalposts do not move once results arrive. The same holds for a rough cut: criteria written after the client has seen it are shaped by what they saw.
7. Get written agreement. An email reply or an approval inside your project tool is enough, as long as it is dated and attributable.

Verifying and documenting acceptance

NASA’s SWE-034 handbook entry defines acceptance testing as formal testing that compares obtained results with expected results. A test passes when results match or fall within an agreed tolerance. That tolerance idea is useful for creative work too. If the loudness target is a specific figure, agree on how much deviation still passes.

The handbook also lists the kinds of criteria worth considering: correctness, performance, throughput, availability and reliability, and documentation readiness. Software teams are the audience, but the categories translate. Correctness becomes “matches the approved script and graphics.” Performance becomes “plays back smoothly on the target device.” Documentation readiness becomes “captions, metadata and usage notes included.”

Record the decision

A sign-off record needs few elements. A UAT sign-off template includes the status of each criterion, any conditions of acceptance, and a formal decision of accepted, accepted with conditions or rejected, supported by signatures. For a creative project that translates to:

For the sign-off flow itself, see our first deliverable sign-off checklist. If you want a lighter review structure, the two-round creative approval workflow shows how to cap revisions so acceptance does not drift.

Common mistakes

• Vague adjectives. “High quality,” “modern” and “engaging” cannot fail. Pair each with a reference or a number.
• Describing the method. “Use After Effects” is a process note, not a criterion. State the outcome the client needs.
• No named approver. If three people can say yes or no, the deliverable will bounce between them. Name one accepting person.
• Criteria that grow mid-project. New ones are a change request. Log them, price them, and agree them in writing.
• Feedback that is not tied to criteria. Review comments are most useful when they point to a criterion that is not met. Our client feedback guidelines cover how to collect notes so they map back to the brief.
• Forgetting the handoff. A perfect file that arrives in the wrong place, without captions or the agreed naming, still fails. The agency content delivery checklist covers what to include.

When a production team and a client need to agree on outputs, review outcomes and what counts as complete, the same discipline applies even to licensed media, as in music video licensing, where the usable formats and deliverables are spelled out before purchase.

A reusable template

Copy this block into your brief for each deliverable.

Deliverable: name, version, due date

Accepting person: name and role

Criteria (pass/fail):

1. Format and specs match [reference document].
2. Content matches [approved script/storyboard/style guide, version].
3. Quality threshold: [measurable standard and tolerance].
4. Completeness: [list of included files, captions, source files, metadata].
5. Delivery: [method, location, naming convention, deadline].

Verification: who checks, with what, against what sample or reference

Review rounds included: number, and what happens after

Decision: accepted / accepted with conditions / rejected, name, date

Perspective

Most disputes we see in post-production are not about quality. They are about two people holding different pictures of “finished,” and nobody having written either one down.

That is why we built Posthive around the idea that the client owns the deliverable and its versions. When the version being judged, the notes against it and the approval all live in one workspace, acceptance criteria stop being a document in someone’s inbox. They become the thing the review is measured against.

Our approach is to pair every deliverable with its criteria, keep each review tied to a specific version, and give clients and team members full access without counting seats, since unlimited free seats are part of every plan. A criterion nobody can see is a criterion nobody applies.

If you do one thing after reading this, write the criteria before the first cut exists. It is the cheapest hour you will spend on the project.

Lorenz

Keep criteria, versions and approvals in one place

Posthive is a cloud post-production workspace that combines version control, task and deadline tracking, collaborative review, client feedback and approval tracking, and secure media delivery. Teams can attach criteria to a deliverable, review against a specific version and keep the approval record next to the files.

Every plan includes unlimited free seats, so clients and collaborators can review without adding to your bill. Paid plans are Pro at $49 per month and Enterprise at $99 per month. You can also explore the Posthive workspace to see how it fits your review flow.

FAQ

What is the difference between acceptance criteria and a definition of done?

Acceptance criteria are specific to one deliverable or story and say when that item is accepted. A definition of done is a shared checklist applied to every item, such as “reviewed, exported and archived.” Use both: the definition covers the team’s standards and the criteria cover this client’s requirements.

How many acceptance criteria should a deliverable have?

There is no fixed number, but three to eight pass/fail statements cover most creative deliverables. Guidance recommends keeping them relatively high level yet useful. If you need dozens, split the deliverable into smaller ones or move detail into a spec sheet that the criteria reference.

Who should approve the criteria?

The person who will accept the deliverable should approve them, alongside the creative lead and whoever will check the work. Collaborative sessions with stakeholders and the team make gaps visible early. Record the approval in writing so it can be referred back to later.

Can acceptance criteria change after the project starts?

They can, but treat each change as a request: agree it in writing, adjust the schedule or budget if needed, and update the criteria for the affected deliverable. Writing criteria before work begins keeps the goalposts from moving without anyone noticing.

What if a deliverable only partly meets the criteria?

Use a status of accepted with conditions. List the failed criteria, the fixes required and a due date, then confirm the fixes against those same criteria. This keeps the second review short and objective.

Sources

• Developing and Using Acceptance Criteria, Ohio Office of Budget and Management
• Acceptance Criteria: Everything You Need to Know, Scrum Alliance
• Acceptance criteria, OPEN, Center for Project Innovation
• Specifying Features and Their Acceptance Criteria, InformIT
• SWE-034 Acceptance Criteria, NASA Software Engineering Handbook
• How to Write Acceptance Criteria for a Scope of Work, RN Digital
• End-User Acceptance Testing for Enterprise SaaS
• UAT Sign-Off Template, QAPractices

Recommended

• Checklist First Deliverable Sign Off for Project and Creative Leads
• A Deliverables Checklist Keeps Every Project Output on Track
• Deliverable Version Tracking: A Media Team’s Practical Guide
• Two Round Creative Approval Workflow for Production Teams