What is the best definition of an acceptance criterion?
Choose an answer, then check it.
Project Management · Foundations
Project Scope
On this page 9 sections
In 30 seconds
project scope The bounded description of the work and deliverables a project is intended to include. Full entry → describes the work and deliverables a project is meant to include, along with useful boundaries on what it will not include. A clear scope connects a project’s purpose to observable outputs and acceptance criteria Conditions that a deliverable must meet before it is accepted. Full entry →—the conditions used to judge whether an output is ready to accept. Scope can change when circumstances warrant it, but an unreviewed expansion of work can create confusion and strain resources.
Why this matters
Scope gives people a shared way to ask, “What result are we trying to deliver, what work belongs to that result, and how will we recognize it?” That clarity supports discussion, planning, and later evaluation without promising a perfect prediction. It also makes exclusions visible, so an appealing request can be considered instead of silently becoming extra work. Learning the distinction between a justified, reviewed change and uncontrolled scope growth helps students read project cases carefully.
The college version
Scope makes a project’s intended work and results discussable
Project scope is the bounded description of what a project is intended to produce and the work needed to produce it. It is not merely a slogan such as “improve service,” and it is not every activity that someone might find useful. A broad purpose can explain why an effort exists; scope translates that direction into a more usable account of included results and work. In practice, the detail appropriate to a scope description depends on the setting and the project’s maturity. Early language can be high level, then become clearer as relevant information is gathered. The educational point is not that one document format fits every project. It is that people need a shared, sufficiently specific basis for deciding whether proposed work belongs to the effort.
A scope description commonly identifies deliverables. A deliverable A unique, verifiable product, result, or capability produced by a project or part of it. Full entry → is a unique, verifiable product, result, or capability a project is expected to produce. A revised public-information page, a tested orientation module, and a handoff guide might all be deliverables in a hypothetical project. A deliverable should not be confused with a hoped-for long-term benefit. A team may deliver an orientation module; whether every new participant feels prepared depends on many conditions after delivery. Keeping output and hoped-for outcome distinct makes project claims more honest.
Scope also benefits from explicit boundaries. An exclusion A result, activity, or need explicitly identified as outside the current project scope. Full entry → says that a particular result or activity is outside this project. Exclusions do not declare an idea worthless. They clarify that the idea is not part of the current commitment, unless it is later considered through the project’s own decision process. A boundary can prevent two common errors: assuming that every related need is automatically included, and treating an excluded need as though no one is allowed to discuss it. Scope is a tool for shared decisions, not a way to silence legitimate concerns.
Deliverables need acceptance criteria, not just attractive descriptions
A deliverable names what the project is expected to provide. Acceptance criteria name the conditions that must be met before that deliverable can be accepted. The distinction matters because names alone leave room for incompatible interpretations. “Create an accessible event-registration page” says more than “improve registration,” but it still requires a way to determine whether the page meets the agreed conditions. Criteria might specify observable conditions such as whether the required information is present, whether stated accessibility checks have been completed, or whether a designated reviewer has confirmed a defined result. The right criteria depend on the project; this lesson does not prescribe a universal checklist.
Acceptance criteria are not the same as a task list. “Hold a review meeting” describes an activity. “The page contains the required registration fields and passes the agreed review” describes conditions for accepting an output. Nor are acceptance criteria a guarantee that a project will achieve every hoped-for impact. They provide a transparent basis for deciding whether a particular deliverable meets the conditions that were agreed for it. GAO’s project-management discussion describes scope validation as formal acceptance of completed deliverables by comparing actual results with the requirements baseline An approved reference point for requirements used to compare actual results and changes. Full entry →. That principle illustrates why a vague finish condition causes problems: people may complete work but still disagree about whether it satisfies the intended result.
Criteria should be understandable to the people who must use them. “High quality” may express an aspiration, but by itself it is too ambiguous to resolve a disagreement. A stronger statement ties the deliverable to a concrete, observable condition. Precision does not require pretend certainty. A team can identify what it knows, state which conditions will be used for acceptance, and revise its shared understanding when evidence justifies doing so. The later Requirements lesson addresses how needs and detailed conditions are elicited and represented; the later Quality Management lesson addresses broader quality practices. This lesson stays focused on the role of scope boundaries and acceptance conditions.
Change can be responsible; uncontrolled expansion is a different problem
Projects learn. A new accessibility need, a changed regulation, a discovery during testing, or a clearer understanding of a user’s situation may make an original scope incomplete or no longer appropriate. Therefore, change itself is not evidence of poor management. A proposed change can be described, considered against the current scope and constraints, and decided through the governance appropriate to that setting. The precise authority, records, and approval steps vary by organization and project; this general lesson does not provide organizational or contractual advice.
scope creep Uncontrolled or unreviewed expansion of project work or product scope beyond the agreed scope. Full entry → is commonly used for an uncontrolled or unreviewed expansion beyond the agreed work. It often arrives in small pieces: “while you are already changing that page, add another form,” followed by “add one more audience,” followed by a request for a new reporting feature. Any individual request may be reasonable. The problem is not that a request exists; the problem is treating added work as free, automatic, or invisible. PMI materials describe explicit exclusions and documented scope as ways to manage expectations, and GAO describes monitoring and managing changes to baseline requirements. Those sources support a practical distinction: a reviewed change updates the shared understanding; a hidden accumulation weakens it.
A scope boundary A stated limit that helps distinguish included work or results from those not included. Full entry → also has limits. It cannot predict every discovery, guarantee a schedule or budget, settle conflicting stakeholder values, or make a project beneficial. It can, however, make the current commitment visible enough for people to identify variance and make deliberate choices. That is especially valuable in classroom cases: rather than calling every new request “bad,” ask whether it fits the stated deliverables and exclusions, whether it changes acceptance conditions, and whether its consequences have been considered. Detailed requirements, work decomposition, and formal change-control design belong to later lessons.
Eli explains
The same idea, in plain words
Explain it like I’m 10
Project scope is like making a clear list for a school fair. The list says what the fair team is going to provide, such as three game booths, signs, and a cleanup plan. It also says what the team is not going to provide, such as running a full concert. That does not mean a concert is a bad idea. It means the fair team cannot quietly add it and still pretend the original job is unchanged.
For each item on the list, the team also needs a way to tell when it is finished. “Make signs” is a job. “Each booth has a readable sign with its name, time, and price” is closer to an acceptance criterion. It gives people something they can check together.
Picture it like this
Think of scope as the border on a puzzle tray. The border does not show every piece of the picture, but it tells you which pieces belong in this puzzle. Deliverables are the completed sections, and acceptance criteria are the checks that tell you whether a section is really complete enough to place in the tray.
Where the picture stops working
Real projects are not puzzles with fixed pieces. New information can justify changing their boundaries, and people may disagree about what counts as useful or complete. The analogy also cannot decide who should approve a real change or what an organization’s rules require.
Worked example
A city library has a hypothetical project to create a pilot webpage that helps residents find digital-literacy workshops. Its scope includes one webpage, a workshop calendar drawn from current library information, and a short handoff note for staff. It excludes building a new registration system and creating workshops for every city agency. Acceptance criteria for the webpage include that it lists the agreed workshop details, uses the existing library platform, and is reviewed against the project’s agreed accessibility check. During review, someone asks to add online payment for unrelated events. The request may be worthwhile, but it does not automatically fit the pilot’s scope. The team can record and consider it rather than quietly treating it as included work. This is an illustrative example, not operational advice for a library.
Key takeaway
Project scope makes the current project commitment visible: what it includes, what it excludes, which deliverables it expects, and how acceptance can be judged. It supports thoughtful change without treating change or success as automatic.
Quick check
3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.
Which statement is an exclusion in a project scope?
Choose an answer, then check it.
A project is producing a workshop webpage. Midway through, a colleague asks the team to add a new citywide event-payment system. What is the strongest first conclusion?
Choose an answer, then check it.
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related
You’ll learn to
- Define project scope as included work and deliverables, stated with meaningful boundaries.
- Distinguish a deliverable, an exclusion, and an acceptance criterion.
- Explain why scope is more specific than a project’s broad purpose or charter.
- Apply scope boundaries and acceptance criteria to a short hypothetical project.
- Analyze why an unreviewed addition differs from a considered scope change.
Common mistakes
Treating a project’s broad purpose as a complete scope description.
Connect the purpose to included deliverables, work boundaries, and exclusions that people can discuss.
Assuming an exclusion means a related idea has no value.
An exclusion identifies what is not in the current commitment; the idea can still be considered separately or later.
Calling a task an acceptance criterion.
A task is work performed; an acceptance criterion is a condition used to judge whether a deliverable can be accepted.
Treating every scope change as scope creep.
Change can be considered and approved; scope creep refers to expansion that is uncontrolled or unreviewed.
Assuming a scope statement guarantees benefits, cost, or schedule outcomes.
Scope supports clarity and decisions, but it cannot remove uncertainty or guarantee results.
Easily confused
Project purpose vs. Project scope
Purpose explains the high-level reason for an effort; scope bounds the work and deliverables intended to address it.
Deliverable vs. Acceptance criterion
A deliverable is an output to be produced; acceptance criteria are conditions used to determine whether that output is acceptable.
Reviewed scope change vs. Scope creep
A reviewed change is deliberately considered and reflected in the shared baseline; scope creep is uncontrolled or unreviewed expansion.
Key vocabulary
- project scope
- The bounded description of the work and deliverables a project is intended to include.
- deliverable
- A unique, verifiable product, result, or capability produced by a project or part of it.
- scope boundary
- A stated limit that helps distinguish included work or results from those not included.
- exclusion
- A result, activity, or need explicitly identified as outside the current project scope.
- acceptance criteria
- Conditions that a deliverable must meet before it is accepted.
- requirements baseline
- An approved reference point for requirements used to compare actual results and changes.
- scope variance
- A difference between the current project work or result and its established scope reference.
- scope creep
- Uncontrolled or unreviewed expansion of project work or product scope beyond the agreed scope.
Sources & references
- A Guide to the Project Management Body of Knowledge (PMBOK Guide), Sixth Edition: Scope Components — Project Management Institute
- Information Technology: Education Needs to Address Student Aid Modernization Weaknesses (GAO-23-105333) — U.S. Government Accountability Office
- Scope Creep: Not Necessarily a Bad Thing — Project Management Institute
EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.
Researched 2026-08-20
Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.