Well, let us start with understanding what is the Definition of Done (DoD) in Scrum?
Per 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”
So, for a team that is developing software product, DoD may be something like
- Code reviewed
- Unit Tested
- Unit Test Coverage 100%
- Integration tested with no defects
- Performance tested with no defects
- Security Tested with no defects
- Acceptance Tested with no defects
Essentially, DoD is a quality commitment that the Scrum team commits to delivering to its customers.
Now here is a question for you, do you think deployment to production should be part of definition of done?
Wouldn’t it be ideal to have your increment or item be deployed to production and then call it “done”?
For most teams, this may not be possible however as the scrum teams mature in their way of working and improve their development process and if it aligns with product owners plan, they may choose to add deployment to production to definition of done. There are times when product owner would have separate roll out plan to product and would not want the items to be rolled out to production, as and when they are ready.
How does Definition of Done help Scrum Team?
As the Scrum guide states, “Definition of done is a formal description of the state of the Increment when it meets the quality measures required for the product”.
From manufacturing floor to software development, this formal description has been stated in form of checklist to control processes and quality of products being produced.
Definition of Done is a similar checklist that is used by Scrum team to ensure quality of the increment they are producing but this checklist is not a static checklist, rather it is improved over time, with the intent to improve product quality.
Having a clear Definition of Done (DoD) ensures transparency within the Scrum Team and also with the customers who are receiving the product.
Everybody in the team understands what needs to be done for every product backlog item, so it meets the DoD, which ensures quality of the increment. This leaves no room for confusion within the Scrum Team.
Towards the end of sprint, DoD is used to identify which product backlog items can be called as “Done” and which is not done. If a product backlog item does not meet the DoD, then it should not be part of the increment and the item should be put back into the product backlog.
By clearly defining DoD, it helps Scrum Teams to deliver on the increments, which goes on to build trust within themselves, as well as with customers. Transparency on when to call an item as “done”, reduces chances of communication gaps and conflicts.
Well another question that comes to mind is – who exactly is responsible to create Definition of Done in scrum?
Ideally Definition of Done is defined as organisation standard. In case DoD does not exist, the Scrum Team, being a self-managed team, should create it. If there are multiple scrum teams, they all should get together and define a common DoD.
Okay, now DoD is created but who is responsible to conform to the Definition of Done in scrum?
Simple isn’t it, people who are actually doing the work are responsible to conform to the definition of done. Scrum teams are self-managed team, so they need to have their own governance process in order to ensure that they are conforming to their own definition of done.
What if there are multiple Scrum Teams?
If there are multiple Scrum teams working on the same product, they should come together and define a common Definition of Done, since they need to produce an integrated increment every sprint. A common DoD ensures transparency across scrum teams, which greatly reduces complexity.
How is Definition of Done different from Acceptance Criteria in User Stories?
Here are the differences between DoD and Acceptance Criteria
|
Definition of Done (DoD) |
Acceptance Criteria |
|
DoD defines quality of the product |
Acceptance Criteria defines business requirements. |
|
DoD is a list that applies to all the product backlog items/user stories, it is not specific to any one story |
Acceptance Criteria is a list of criteria that is specific to a user story. |
|
DoD can be organizational standard or created by scrum team |
Acceptance criteria is usually defined by Product Owner |
|
DoD is not changed or negotiated with PO during sprint to meet the sprint goal |
Acceptance Criteria can be negotiated with PO during sprint to meet the sprint goal |
How often is the Definition of Done changed in Scrum?
Definition of Done ensures quality of the product, so whenever we learn better ways to improve quality, scrum teams should come together and make changes to their DoD, so as to improve the quality of their delivery. Ideally DoD should be reviewed in sprint retrospective to check if there are any room for improvements.
You found a gap in your process that is leaking defects, should you wait until retrospective for you to make changes to Definition of Done?
As Scrum guide says about any variance found in any of the process – “The adjustment must be made as soon as possible to minimize further deviation”. Definition of Done would be no different.
If you are under a tight deadline, should you make changes to Definition of Done, so you are able to meet the deadline?
Definition of Done (DoD) ensures quality of the product. In situations where one is running into a tight deadline, does it make sense for scrum teams to compromise on quality by making changes to DoD?
In such situations, developers should work with the Product Owner and negotiate on the Product backlog items, such that they deliver their sprint goal without compromising product quality.
