accepterkriterier

Accepterkriterier, often translated as acceptance criteria, are the conditions that a product increment must satisfy to be accepted by a customer, user, or product owner. They accompany a requirement or user story and provide a written, testable definition of done for that item.

They guide development and testing, clarify scope, and provide a shared basis for evaluation and decision making when requirements change. By detailing what must be true for a story to be considered complete, they help teams avoid scope creep and misaligned expectations.

Characteristics of good accepterkriterier include being specific, measurable, testable, unambiguous, and independently verifiable. They should focus on outcomes and user value rather than implementation details, and ideally be agreed upon upfront by stakeholders to enable objective testing.

In agile projects, acceptance criteria are often stated as Given-When-Then scenarios and used to drive test cases, manual or automated, ensuring that the story is complete from a user perspective. They sit at the story level, complementing higher-level plans and the team’s broader quality standards.

Relationship to other concepts: accepterkriterier are distinct from the broader definition of done and from non-functional requirements. They define the acceptance tests for a specific story, while the definition of done covers overarching quality attributes, integration, and release readiness.

Example: For the user story “As a user, I want to reset my password so I can regain access,” acceptance criteria include: a reset email is sent within two minutes; the reset link expires after 24 hours; the new password is at least eight characters; the flow handles invalid emails gracefully; and messages are localized and accessible.

Best practices include involving stakeholders in writing criteria, avoiding vague terms, keeping criteria small and testable, and linking criteria to test cases and automated tests where possible.