Acceptance Criteria (ACs)

If a user story outlines the goal, Acceptance Criteria (AC) define the specific rules that prove we've achieved it. For anyone building or estimating software, ACs are non-negotiable for clarity. They transform a potentially ambiguous request into a set of concrete, testable conditions. Think of them as the functional contract for the story: meet these criteria, and the work is done.

Good ACs are specific and objective. Examples: "Verify login with valid credentials redirects to dashboard," "Verify login with invalid password shows 'Invalid credentials' error." Bad ACs are vague and subjective: "Error handling should be robust," "The process should be smooth." How do you estimate or test "smooth"? You can't, reliably.

I also prefer acceptance criteria to be written in a Given-When-Then format, which is directly convertable to the Arrange-Act-Assert format for unit testing. This makes it easier to write tests and understand the criteria.

From an estimation standpoint, clear ACs define the precise scope boundaries. We're estimating the effort needed to satisfy these specific conditions. This drastically reduces the uncertainty compared to estimating a story with fuzzy or missing criteria. While a dedicated QA might focus more intensely on test case generation from ACs, for developers doing estimation, they provide the necessary detail to understand the required functional paths and edge cases involved.