Scrum: Definition of Ready, of Done, Acceptance Criteria

I know that there are as many definitions for the concepts of Definition of Ready, Definition of Done and Acceptance Criteria as there are Scrum Masters. In many cases, the concepts overlap or are included in one another.

Here I will briefly describe how I prefer to use them:

Definition of Done (DoD):

done by: Scrum Team
what is it: technically, a checklist of steps that describe the lifecycle of a backlog item. Starts with the Definition of Ready (where it is used) and ends with the integration of the item in the product increment (some go as far as production delivery). May include various steps covering writing the code, writing various kinds of tests, performing tests (or not, depending on team organization), doing code review, etc.
importance: the Definition of Done allows anyone involved to follow the progress of a backlog item and more importantly it allows for quick decisions regarding change management. It is a coherent list useful both to stakeholders as well as the team who are reminded of what needs to be done in order to complete the work.

Definition of Ready (DoR):

done by: Development Team (some recomm$formation required in order to start work. It should be minimalistic and shouldn't cause downtime in the process. Also, it reminds the PO of what information to gather before the requirement becomes a backlog item (eg: this should be defined before it is added to the backlog).

Acceptance Criteria (AC):

done by: PO (based on his work with stakeholders and their needs/suggestions, might/should involve the Development Team for brainstorming but not to such an extent as to distract them from their work) what is it: a brief description detailing what the backlog item should look like in order to be accepted.
importance: the Acceptance Criteria allow a streamlining of the acceptance process, ensuring a more clear definition and understanding of a Sprint Goal, both by the team and the stakeholders.

An important point I'd like to stress is that none of these items should be seen as unreasinaby set in stone. Changes are allowed up to the point where it makes sense. EG: it's not reasonable to change the AC one day before the end of sprint, might as well drop the item. Or, it makes little sense to change the DoR after the work has started, if you need more details just discuss them and it's something generally need it, then add it to the DoR later.

All in all, none of these concepts should be allowed to become bottlenecks, but also consider that even if it takes a bit longer for a change request to become a backlog item due to a DoR, it may very well make up for that by removing some uncertainties and allowing the team to work better.

Other ideas:

* don't spend too much time on defining these for each item (given that the AA and DoR should be met before the sprint starts), ideally it should be a brief brainstorming
* you won't be able to cover all bases with these documents and you shouldn't waste time trying. Once the work starts, you will always discover things you didn't think of.