Ready, Accepted, Done! Acceptance criteria and definitions of ready and done.

How to know if a task is ready to be started or done to be delivered? A chocolate cake for example, for it to be ready, does it need topping or not?

To align expectations, there are three agreements you should make before starting to develop a product:

• Acceptance or Acceptance Criteria (AC),
• Definition of Ready (DOR),
• Definition of Done (DOD).

In this text I will talk about these three agreements using analogies outside of IT and also examples within software development.

Using these three agreements within a development team is extremely important so that, when a task is delivered, you don't hear from stakeholders "but that's not how I asked you to do it", "how is this ready if this is missing?", or the team "you didn't give me what I asked for, so I couldn't finish it".

Acceptance Criteria (AC)

Stakeholder: I want a chocolate cake in two days.

Dev: Right. With or without topping?

Stakeholder: With topping and filling, but I'm celiac so I need it with rice flour.

Dev: Ok. What size?

Stakeholder: hmm... just for family. Me, another adult and two children.

Dev: I need you to be more specific. Give me exact measurements.

Stakeholder: I want the cake in a 20cm pudding mold.

Dev: Topping with milk or dark chocolate

Stakeholder: 70% dark chocolate

Dev: Any specific brands?

Stakeholder: No. I just don't want with hydrogenated fat

Dev: Anything else?

Stakeholder: No. That 's it.

Dev: Check with me, please:

• Chocolate Cake
• Made with 20cm pudding mold
• 70% dark chocolate, non-hydrogenated
• Rice flour instead of wheat

Stakeholder: Checked!

Dev: Let's define the payment?

---

In this example, we define the acceptance criteria for exactly requested cake to be developed.

In an IT context, this list contains the requirements for a feature to be developed as expected.

Definitions

• Criteria required for a given task* to be considered completed
• Differ for each task
• Answer the questions:
  • Are we building the right thing?
  • Did we build it right?
• Must (need?) be written before start development

*task can be story, subtask, epic…

Example

An endpoint must return the following status codes:

• 200 success
• 401 unauthorized
• 404 not found
• 408 timeout
• 500 server error

So the task cannot be given as completed if it doesn't return at least these statuses. Can it return other statuses besides these? Yes, it can, but it is not recommended to make increments without being aligned with the business party and the rest of the team. Modifications must be added/removed from the acceptance criteria.

Definition of Ready (DOR)

Dev: To start development, I need you to transfer to my account the value of the ingredients or you can have them delivered directly here. Without the ingredients I can't start the development.

Stakeholder: I will order now. Hmm… it says here that delivery will be in two days. Can you do it for the same day?

Dev: I can't. I need at least one day. So the ingredients must be provided by 4 pm the day before you need the cake.

---

In our story, the DOR for cake development is that the ingredients must be available by 4pm the day before the cake is delivered. Coming back to IT,

Definition

DOR are prerequisites for a backlog to be considered ready to start development.

Examples

1. Do we have all the access we need?
2. Do we have the hardware and software needed for development?
3. Do we have written acceptance criteria?
4. Do we have a wireframe, even hand-drawn? (for front end)

Explaining the examples:

1. If the task is to configure Amazon's S3 bucket, is it worth including this task without the responsible person having the necessary access to perform it?
2. Will you be able to start iOS development without having a Mac with XCode installed? It will be hard…
3. Are you going to start developing without knowing what should be developed? You can, but definitely you'll have to rewrite somethings
4. Same as item 3 for the frontend

Definition of Done (DOD)

Dev: Your cake is ready. You can come get it.

Stakeholder: I thought you would deliver it here.

Dev: We forgot to define it…

Although the cake is ready meeting all the acceptance criteria, can we close this task if the cake was not delivered? In this scenario, we have at least two possibilities for defining done:

• cake done with stakeholder going to get it
• cake done being delivered to a certain address

Definition

• DOD is the criteria required for ALL tasks to be considered completed
• Task done = AC + DOD
• It's the same for everything in a given context
• Context can be team, project and/or the entire company
• It is an agreement for all people to follow in a context

Examples

1. Is it pushed (git push)?
2. Is it on staging?
3. Is there error treatment?
4. Was it functionally tested?
5. Was it security/pentested?

Explaining the examples:

1. Is a code that is only on your computer good for anything?
2. If a site is not in an environment that can be validated by others outside the team, is it ready? (May be, depending on team lineup)
3. Let's assume that a frontend consumes the API described in the acceptance criteria example, if the API returns "201 no content" or "206 partial content", how will the front behave? (I've seen infinite loadings on the web and apps crashing in cell phones)
4. It's done, just need to test! (Really? No comments.)
5. In this time when ransomware and data leak are happening a lot, isn't it worth having it in your DOD?

Note that done does not necessarily mean being in production. Done will mean different things in different teams.

To think:

If a task/feature is not able to deliver value, is it done?

So, does your team already practice these agreements? If not, shall you start?