Agile: Definition of Done and Acceptance Criteria

Questions around what is considered to be ‘Done’ and the acceptance criteria come up quite frequently in the Agile world especially when any team is transforming into true Agile or when Business Sponsors wants to know when something will be ready for customer use.

To begin with, Definition of Done (DoD) and Acceptance Criteria are not the same. Acceptance criteria (also interchangeably called as Conditions of Satisfaction) is something that a Product Owner (PO) includes in the User Story to ensure the feature meets the desired behavior and the required performance so that PO can accept the feature. Each criteria is verifiable and they are unique to that particular story. Objective of the acceptance criteria is to ensure everyone has a common understanding of what needs to be built, help write test scenarios and let the team know when the story is considered to be complete.

Definition of Done is a team agreement on what they consider is ready for release at the end of every sprint or continuously through the sprint (CI / CD approach). It is recommended to determine this at the start of a project and the review happens to the user story but not specific to a story. Now what happens when there is tech debt? Is it considered to be done?

Tech Debt is nothing but the quality isn’t at a level where they would like it to be. An example would be hard coded non-localized strings instead of dynamically building it in the app. It’s a quick and dirty work that would help get it to production quicker in the short run but will need to revisit and fix it for future needs for scalability, in which case, the debt gets added to the backlog.

Now if you ask, is tech debt the same as not done? The answer is no. Teams / organization sometimes knowingly take up tech debt and go live to support a business goal like, faster go-to-market (GTM) strategy however, can’t say the same for undone work. Undone work not only puts future sprints in jeopardy but also previous sprints and any work done up until that point at serious risk, especially if it’s threatening to invalidate all the work that’s been done so far. Some teams may take up tech debt but don’t accept undone work because there is too much risk involved in going live.

So DoD is a kind of checklist that all user stories are checked against and it applies to everything in the backlog. Sometimes teams even have two sets of DoD — One at the user story level and another at the release level. The definition may vary from one team to another but it should be consistent within the team and every team member should understand what ‘Done’ really means. It can’t be changed in the middle of a sprint, so have a discussion with the team at the beginning of the project, define the success criteria and document all the things that would make sense to release to the customer and provide value to the business and periodically review it to include a broader definition of done.