Minimum Acceptance Criteria

Mandatory baseline conditions set by a business unit. These conditions are included in the acceptance criteria for every user story from that unit, and any functionality delivered must meet them for the Product Owner to accept the work.

Key Points

  • Defined by the business unit, not by the delivery team.
  • Applied to every user story from that unit as part of its acceptance criteria.
  • They are the minimum bar; story-specific criteria can be added but cannot weaken them.
  • Product Owner acceptance depends on meeting these conditions; unmet items block acceptance.

Example

A finance business unit sets minimum acceptance criteria such as audit logging, encryption of sensitive data, and role-based access. A user story like "Export monthly statements" must implement logging of all exports, encrypt files at rest and in transit, and restrict access to authorized roles; otherwise the Product Owner will not accept the story.

PMP Example Question

In an agile project, what best describes Minimum Acceptance Criteria for a business unit?

  1. The team's Definition of Done for all backlog items across the program.
  2. Baseline conditions set by the business unit that every one of its user stories must satisfy to be accepted.
  3. Optional stretch goals the team pursues if there is extra capacity.
  4. The Product Owner's personal preferences for the current sprint only.

Correct Answer: B — Baseline conditions set by the business unit that apply to all of its user stories

Explanation: Minimum Acceptance Criteria are mandatory, unit-defined conditions included in each user story's acceptance criteria and used by the Product Owner for acceptance; they are not optional, not the team's Definition of Done, and not ad hoc preferences.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Eight teaching sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Take Control of Project Performance!

HK School of Management and Technology helps you go beyond status reports and gut feelings. In this advanced course, you will learn Earned Value Management (EVM) to measure progress, forecast outcomes, and take corrective action. Learn how WBS quality drives performance, how control accounts work, and how to use EAC, TCPI, and variance analysis. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More