Acceptance criteria and the reviewed task breakdown

By the end, you can

• Define acceptance criteria for a task, and explain how they differ from the task's own description (PM-1).
• Critique an AI-generated task plan for missing or unverifiable acceptance criteria, point estimates, oversized tasks or unconfirmed dependencies (PM-1, PM-2).
• Assemble milestones, sliced tasks with estimate ranges, confirmed dependencies and acceptance criteria into one reviewed task breakdown (PM-1, PM-2).

Before you start

This is Module 2, Lesson 3 of the AI-Powered Project Management course, and the last lesson before Module 3's work on risks and decisions. It builds on Lesson 1's milestones, sliced tasks and estimate ranges, and Lesson 2's confirmed dependencies, and closes this module by assembling all four into one document: a reviewed task breakdown.

Acceptance criteria: what "done" actually means

A task description says what to do. It does not say how anyone — including the person doing the work — will know it has actually been done well enough to count. That is the job of acceptance criteria. APM's project management glossary defines acceptance criteria as "the requirements and essential conditions that have to be achieved before a deliverable is accepted," and defines acceptance itself as "the formal process of accepting delivery of a deliverable or a product." Together, these describe a specific, checkable bar — not a general sense that the work looks finished, but stated conditions someone other than the person who did the work could check against the actual result.

"Record video segments" is a task description. "Video segments are recorded, each under three minutes, with clear audio and captions matching the script" is an acceptance criterion — something a reviewer who was not in the room can actually verify. Without that bar, "done" is whatever the person doing the work decides it is, which is exactly the gap acceptance criteria exist to close.

Improving an AI-generated task plan

An AI-drafted task plan is genuinely useful as a starting structure — Lessons 1 and 2 have shown that repeatedly. Left unreviewed, it tends to leave the same handful of gaps, because each one requires knowledge the draft never had access to:

Checking a drafted plan against these four gaps is not a one-off habit specific to this lesson's exercise — it is the same review discipline this course has applied at every stage: the draft is a starting point, and a named lead's knowledge of the real people, real blockers and real bar for "good enough" is what turns it into something the project can actually be held to.

• A single-number estimate instead of a three-point range, hiding how uncertain the estimate actually is.
• A task still too large for one person to own, bundling work that in practice belongs to two different people.
• A dependency the draft could not see, because it depends on a real-world blocker — a vendor's lead time, a shared resource, a required approval — rather than anything the task names reveal.
• No stated acceptance criteria at all, leaving "done" as whatever the task owner privately decides.

Assembling the reviewed task breakdown

A reviewed task breakdown is not a new invention — it is what Module 2 has been building one element at a time. It has four parts, and a breakdown missing any one of them is not reviewed, whatever else it contains:

AI can draft a first pass at all four, the way the earlier lessons in this module have shown. The US National Institute of Standards and Technology's (NIST) AI Risk Management Framework's own description of an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" is exactly why that draft is a starting point, not a finished plan. What makes a task breakdown reviewed is the same discipline this course has applied to every earlier artifact: the named project lead checks, corrects and confirms each element using knowledge the draft never had, before anyone treats the breakdown as agreed. Signing off a reviewed task breakdown is itself the kind of call the Open Worldwide Application Security Project's (OWASP) guidance on excessive agency has in mind when it recommends that a human "approve high-impact actions before they are taken" — committing a schedule, a set of owners and a definition of done is exactly that kind of high-impact action.

• Milestones and sliced tasks — a small set of checkpoints, and the work underneath each one, sliced small enough for one named person to own (Lesson 1).
• Estimate ranges — a best-case, most-likely and worst-case figure for each task, not a single number (Lesson 1).
• Confirmed dependencies — the genuine ordering and resource relationships between tasks, checked against real-world blockers the draft could not see (Lesson 2).
• Acceptance criteria — a stated, checkable bar for what "done" means for each task or milestone (this lesson).

A worked example: a nonprofit's volunteer training programme

The nonprofit programme director closes out her planning work from Lessons 1 and 2. Her AI assistant, asked to produce a full task plan for the "orientation module published" milestone, returns: "Record video segments — 3 days. Build quiz — 2 days. Publish to platform — 1 day." No acceptance criteria are listed for any of the three.

She reviews the draft against this lesson's four checks. The estimates are single numbers, not ranges — she already fixed the video-recording estimate in Lesson 1's worked example, and now adds ranges to the quiz and publishing tasks too, since a platform bug or last-minute revision could plausibly push either one past its point estimate. None of the three tasks state acceptance criteria, so she adds them: the quiz is done when it has at least five questions covering the written checklist and a colleague not involved in writing it can pass it; publishing is done when the module is reachable from the main volunteer sign-up page without a broken link, checked from a second device. She confirms the dependency Lesson 2's pattern would predict — the quiz cannot be built until the orientation script is final, since the quiz questions are drawn from it — which the AI's draft had left unstated. With ranges, criteria and the dependency added, she takes the reviewed task breakdown to her director alongside the bounded project brief from Module 1, as the second artifact in the course's evidence trail.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines acceptance criteria as the requirements and essential conditions that have to be achieved before a deliverable is accepted, and acceptance as the formal process of accepting delivery of a deliverable or a product.
2. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
3. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.