Definition of Done

5 minutes read

The core element of Scrum is the continuous delivery of usable Done increments. But how do we know when an increment is ‘Done’? This is where Definition of Done comes in.

According to Scrum Guide, The Definition of Done (DoD) is a formal description of the state of the increment when it meets the quality measures required for the product. DoD ensures that it is clear to the Scrum team about what all the activities that are needed to be done so that the increment can be ready for release at the end of the Sprint.

In simple terms, a DoD is like a checklist of what all the Scrum team is supposed to finish successfully before declaring the work to be potentially shippable.

DoD broadly fall into 3 types-

  • Definition of Done for a Feature A DoD for a Feature should make sure that every requirement of a user story should be met and fulfilled i.e producing code, reviewing it, testing the story, documenting the changes, testing on browsers/devices, PO accepting it, non-functional requirements etc.

  • Definition of Done for a Sprint A DoD for a Sprint should make sure that all the implemented features within the sprint fulfill the assumptions and all conditions for production deployment are met i.e bugs are fixed within the code, performance testing is finished, DoD of each user story included in the sprint is met, product backlog updated, backward compatibility tests passed, stories/features deployed on test environment identical to production environment etc.

  • Definition of Done for a Release A DoD for a Release lists the criteria like code fully complete, quality testing, environments are set up for release, unit and functional tests are all passing, regression testing, approval from all necessary stakeholders and the team (QA, developers, UX, software architect etc), continuous integration is working etc.

Common DoD Checklist

  • The story is signed off for development by all necessary stakeholders
  • Design is reviewed
  • Code meets general standard format
  • Code is refactored
  • Code is peer reviewed
  • Code is checked in
  • Code is deployed to test environment
  • Code/feature passes Unit testing
  • Code/feature passes Integration testing
  • Code/feature passes Regression testing
  • Code/feature passes Platform testing
  • Code/features passes Language testing
  • Code is documented
  • Acceptance testing
  • NFR’s are met
  • Live on production servers

Who defines DoD

If the Scrum team is not speaking the same language, there is ample room for confusion, frustration, blame. In order to avoid all this, there should be a common vocabulary which is defined by the developers, testers and the product owner to agree what qualifies as ‘Done’ in different cases. The Dod must be defined collaboratively and should not happen in a vacuum. One must think of all the smallest of smallest tasks that needs to happen to put the story into production.

Benefits of DoD

The benefits of creating a DoD are -

  • Eliminates risk as all activities are listed down so there is less likelihood that any important activity will be missed.
  • Minimises misunderstanding among team members as each member know when will a user story, sprint or release be considered as done to meet the customer needs.
  • It brings transparency as everyone knows what needs to be done and what does NOT need to be done.
  • Less rework cost once the stories have been accepted as ‘done’.
  • The team can gauge how much they can realistically work within each sprint.

DoD versus Acceptance Criteria

While DoD are generic to all stories, Acceptance Criteria are specific and different for each story. DoD is a checklist that all user stories must adhere to for the team to call them as complete while the Acceptance criteria are scenarios specific to each user story which must be met to confirm that the user story is complete. However, please remember that both DoD and Acceptance criteria must be met in order to complete the story and release it.

Acceptance criteria provide details from a testing point of view for a story. Acceptance criteria usually include - Use cases (functional and nonfunctional), end to end user flow, negative scenarios of the feature, UX concerns, what feature must do/must not do etc. They can be simple, or follow BDD (behaviour driven development) format of Given-When-Then.

Example User Story with Acceptance Criteria

As a customer care operator
I want to update a customer’s phone number on the system
So that the new phone number will be used to contact the customer

A few example scenarios would be

Scenario - Update phone number with a valid phone number

Given I have a customer with an existing phone number on the system
When I enter a new valid phone number
Then the new phone number request is processed successfully
And I can see the customer’s new phone number on the system

Scenario - Update phone number with an invalid phone number

Given I have a customer with an existing phone number on the system
When I enter a new invalid phone number
Then the new phone number request is not processed successfully
And I can see an error message that shows that the phone number is not valid

Simple statements

  • When the customer care operator inserts the customer details, it must be validated
  • Once the details are validated, confirm the account is active
  • After the customer enters the phone number to be changed, verify the phone number is valid or invalid to update the records
  • If valid, update the phone number and display to the customer care operator that the phone number has been successfully updated
  • If invalid, don’t update the phone number and display to the customer care operator error message that the request cannot be processed

Conclusion

DoD differs across every team and across every organization. Preparing a single DoD for every team is uncalled for and each team should collaborate and come up with their own DoD. The kind of product being developed, technology being used to develop it, the obstacles that can impact the possibility of it being built all help define the DoD.

Remember that the DoD can be improved via feedback from retrospective meetings. Tweak and adjust your DoD until they deliver what you aimed for. I’ve worked with quite a few teams who aren’t aware of, or forget about, the Definition of “Done”. In my opinion, this is one of the easiest, low effort, high impact elements of Agile that a team can adopt.