Out of Scope
Out of scope describes the work, features or behaviors that a project or release deliberately will not include. Written as an explicit list in a PRD, brief or project plan, it marks the outer edge of what the team is committing to, so stakeholders, designers, engineers and AI coding agents do not assume more than was agreed.
How Out of Scope Works
The BABOK Guide defines scope as the boundaries of a change, a solution or a need. An out-of-scope section states the outside of that boundary in plain words. Project managers call these items project exclusions, and Joel Spolsky's classic advice on functional specifications calls them "nongoals".
Useful entries are specific and, where possible, say why or where the item went:
- "Bulk editing: deferred to the next release."
- "No native mobile app in v1; the web app will be responsive."
- "We will not migrate data from the legacy system."
Vague lines such as "advanced features" do not help, because nobody can check against them. Out of scope also does not mean "never". Many items move to the product backlog or a later release once the current one ships.
Why Out of Scope Matters
An explicit exclusion list prevents scope creep, surfaces mismatched expectations before work starts and makes estimates more honest. It is especially useful when defining a minimum viable product (MVP), where the hardest decisions are about what to leave out.
The section matters even more for AI coding agents. An agent asked to build a feature will often add plausible extras or change nearby code. Stating what it must not build or touch, such as "do not modify the billing module", keeps changes contained. For more on this, see how to structure backlog tickets so coding agents do not invent product scope.
Out of Scope Example
A team scheduling app plans its first release. In scope: create shifts, assign staff and send email notifications. Out of scope: shift swapping between staff (next release), payroll export, SMS notifications and native mobile apps. When a sales lead asks for SMS alerts mid-sprint, the product manager points to the list, adds the request to the backlog and the sprint stays intact.