Definition of Done vs. Acceptance Criteria: What's the difference?

WHAT THIS TESTS: This question assesses your practical experience with Agile quality frameworks, not just textbook definitions. The interviewer is probing your understanding of accountability, quality ownership, and the difference between a universal team standard (DoD) and a specific feature's requirements (AC). They want to see if you can connect these process artifacts to the ultimate goal: delivering a valuable, working product Increment that is truly 'done'.

A GOOD ANSWER COVERS: A strong answer addresses four key points in order. First, Definition and Scope: The Definition of Done (DoD) is a single, global checklist that applies to ALL work items, ensuring consistency. Acceptance Criteria (AC) are unique to a single Product Backlog Item (PBI), defining its specific requirements. Second, Purpose: The DoD ensures the Increment is of high quality and potentially shippable. The AC confirms a specific story is complete and delivers the intended user value. Third, Ownership: The entire Scrum Team (Developers, PO, Scrum Master) collaborates on and owns the DoD. The Product Owner is primarily responsible for writing AC, ideally in collaboration with the Developers. Fourth, Contribution to Value: AC ensures you built the right thing. The DoD ensures you built it the right way. Together, they create a valuable Increment.

COMMON WRONG ANSWERS: A major red flag is using the terms interchangeably or suggesting the DoD is just a more technical set of AC. Another weak answer is defining the DoD as simply 'the ticket is moved to the Done column'—that describes a workflow state, not a quality standard. It's also a mistake to say only the Product Owner writes AC in a vacuum, or that only QA is responsible for the DoD. This signals a misunderstanding of collaborative, whole-team ownership. Finally, describing AC as a list of technical implementation tasks is incorrect; AC should focus on user-observable behavior and business value.

LIKELY FOLLOW-UPS: Expect questions that dig into real-world application, such as: 'Tell me about a time you had to push back because an item didn't meet the Definition of Done.' Or, 'How would you handle a situation where the team consistently fails to meet its DoD?' Or, 'Describe how your team's Definition of Done has evolved over time.'

ONE CONCRETE EXAMPLE: For a 'User Login' story, the Acceptance Criteria would be specific to that feature: 1. When a user enters correct credentials, they are logged in. 2. When a user enters incorrect credentials, they see an error message. The Definition of Done applies to this story AND all others: 1. Code is peer-reviewed. 2. Unit test coverage is above 85%. 3. All AC are met and verified by QA. 4. The feature is deployed to staging without breaking the build. 5. Any new secrets or configurations are documented.