Definition of Done and Definition of Ready

What is the difference between Definition of Done (DoD) AND Definition of Ready (DOR)?

Definition of Done

According to the 2020 Scrum Guide:

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

To put it simply: The user story is really Done when it meets all the criteria of the DoD.

So when the PO asks : is the user story done? Your answer is “YES“, and not “yes but we are only missing the unit tests“.

If you are looking for inspiration, here are some criteria of a DoD for a user story:

  • Functional tests are executed
  • Acceptance tests are executed
  • No critical bugs
  • Code coverage over 80%
  • Unit tests completed
  • PO saw a demo and gave the OK

Take the first letters of each criteria and it spells FANCUP. Here’s an image to help you remember it :

Definition of Ready

TheĀ  DoR comes before applying the DoD. The 2020 Scrum Guide only mentions this:

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

The Scrum Guide doesn’t explicitly call it the Definition of Ready, but you can somehow read it between the lines.

The main goal is to make sure the user story is in a state of “ready” so that you can easily take it in the Sprint Planning. For those who haven’t defined the DoR, how many times did you arrive at a Sprint Planning, spend 30min to discuss a user story to only realize that the user story isn’t ready to be worked on? That’s what the DoR is trying to address.

So what are some examples of criteria that makes a user story ready for the next sprint?

  • user story is broken down as small as possible
  • acceptance criteria is clear
  • out of scope items are defined
  • it has been presented to the Development team
  • user story has story points

When does the team define them?

Ideally, you should have a DoD and DoR before starting Sprint1 in a perfect world… but then again we aren’t perfect .

As long as you do it and revise it every once in a while, you’re good.

The revision part is important because the team will evolve and they will adapt the DoR and DoD as a consequence. When is a good time to revise them?

At the Sprint Retrospective!!

Who participates in the DoD and DoR?

  • the Development team
  • the PO
  • the Scrum Master (as facilitator)

It is really the PO and Development Team that decides what goes in a DoD and DoR. The SM is there to facilitate the meeting. Avoid doing the meeting without the PO.

Can we have many definitions of done?

Some people will categorically say NO but then again , if the goal is to help your team be more efficient and improve the quality of the increment, why not?

Here are some examples where you may want to consider the DoD… or if you don’t want to use that term, call it the Definition of CompleteĀ 

  • what do you need in order to publish to PROD (documentation, NFR tested, automated end-to-end tests …)
  • do different types of user stories need different DoD: e.g. some are only for API, some are only for front-end
  • do you want to distinguish the DoD between dev and qa?

What to do when the dev is done before the Sprint ends?

There are 3 days left in your Sprint and your devs are done. Now what?

Do you take on new user stories?

I know , it’s very tempting, and we’ve done it too.  Devs are happily coding while QAs are trying to finish their tests. Sadly, sometimes QAs didn’t have time to finish their test and the team hasn’t been able to complete their user stories. But hey, at least the devs had something to code, right? In this situation is a missed out opportunity for the team to work as a “team” with the same goal: deliver a Product Increment. 

I’m not saying it’s wrong to start the development of user stories in the next sprint. However, I would strongly recommend first looking at how can devs help the other team members complete the user stories. 

So what else can the devs do?

  • Is there another user story where the development isn’t finished? Can you break it into smaller tasks and split it with other devs? How about writing their unit tests? How about pair programming?
  • Can you execute some QA tests? If the steps are written, you should be able to follow the steps and do them. I recommend testing another user story, not the one the Dev have written.
  • Are there  any integration or end2end automation tests that can be written? Can you help with the setup of the QA automation infrastructure?

What do your devs do before the end of the Sprint?

Developer

Are you listening to your internal alarm?

I was living in a condo when the fire alarm rang in the middle of winter. I wasn’t sure if it was a false alarm. I wondered if I should wait and see if it’ll stop or if I should I start walking more than ten flight of stairs . Eventually I listened to the alarm, grabbed my coat, and headed outside.

In this situation, the fire alarm was external and extremely audible. There was no way for me to ignore it. Easy enough to pay attention to, right? But what about all the alarms we don’t visibly see or hear. 

Some of us feel it inside that something is wrong but we don’t listen to our internal alarm, our “gut feeling”.

Could you be in a friendship where all your friends do is take from you but never give? They expect you to always be available when they need something but when it’s your turn, they somehow are always busy. You know something is wrong but  you are just too afraid to lose a friend. Your alarm is buzzing but it’s too faint for you to listen to it. You don’t even think of asking yourself, is this friend really a friend and what forces me to stay in this kind of friendship? They are my friends since kindergarten…so what? Are they treating you like a good friend, are they caring about you? Who says the longest lasting friendships are the right ones for everyone?

Could you be in a toxic or abusive relationship? Shouldn’t those visible bruises be an alarm ? Should you be getting help to get out of that situation? It may not be firefighters in this case but there’s definitely someone who can help. 

Could you be working in a toxic environment, causing you unfair stress and lack of sleep? Do you feel that your personal boundaries are being overstepped? Is it normal that during the weekend when you should be off that your boss is texting you to do some work? Do you feel like you can do so much more  than the tasks being asked of you? Are you afraid to ask for better opportunity, better salary that you deserve, better work environment? Why? Isn’t this fear some type of alarm?

When something doesn’t feel right, listen to your self, pay attention…is this my internal alarm ringing?