How is definition of done defined and why does it matter?
Welcome to part 56 of our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
What is a Definition of Done?
You’ll often refer to the ‘definition of done’ as a checklist for developers or product development teams. Fair enough. It can be that, but it’s intended to be more valuable than a simple checklist.
In the latest 2020 version of the scrum guide, the definition of done is referred to as the scrum team’s commitment to producing the increment. The working piece of software or product that the team deliver to a customer for review and feedback.
So, we are talking about the quality of the increment. The quality of the work item being built for the customer or product stakeholder.
You can think of a definition of done as the minimum standard of quality that the scrum team commit to delivering as part of a working product. The criteria that must be met for the product or feature to be considered valuable to a customer.
Determining quality control criteria
In the product backlog refinement session, the developers will work closely with the customer, product stakeholders, and product owner to identify what needs doing, why it matters, and how that item will have a positive impact in a customer’s job.
They will identify all the criteria that must be met for the product or feature to be considered a successful addition to the client environment.
Some of that will be technical, some of that may be testing-based, and some of it may be legal or compliance elements that must be met before it enters a client environment.
All the criteria are documented, and agreement is reached about what ‘finished’ looks like.
The scrum team articulate this definition of done at the START of the work item’s journey through development so that everyone is clear about what a completed work item looks and feels like. So, everyone is clear about what needs doing for the increment to be considered a success.
Defining these criteria and making them visible in the product backlog or the sprint backlog enables the team to work with transparency, which is a critical component of empirical process control.
Transparency. Frequent Inspection. Adaptation based on data and feedback.
We want the product owner, customer, and product stakeholders to see where we are currently at with the product or feature, what still needs to happen before the product is delivered, and that we are making steady progress with the work item throughout the sprint.
It helps manage expectations, it helps increase customer satisfaction, and it helps avoid mistakes because everyone is aware of what is happening, why it is happening, and what the criteria for a successful product increment are.
If something is incorrect or we have needless items in the ‘definition of done’, it is quick and easy for anyone to bring that to the developers’ attention and amend as necessary. That is the value of transparency and having a clear definition of done in the work item.
Product Backlog Refinement
For me, the definition of done plays a critical role in successful product backlog refinement meetings.
It gives us an opportunity to inspect what must happen and decide whether the item needs to be refined to ensure that we are able to get through the work quickly and effectively.
- Have we thought about the governance issues related to this work item?
- Have we considered the documentation that must accompany this work item?
- Have we considered the collateral impact of this item on another work item?
- Have we thought about the user research this item entails?
- Have we thought about how to effectively test whether this works?
And so forth.
It may make sense to create a separate work item for the documentation element of the item. It may make sense to create a separate work item for the governance criteria. Do we need to work on this as a big chunk of work or can we divide it into simpler, smaller components that are quickly and easily completed?
All these elements matter but they aren’t necessarily considered, by default, when we first encounter the work item and get caught up in how to solve the problem.
Backlog refinement sessions solve that problem and ensure we are working effectively.
So, a definition of done can become the lynchpin in the whole operations element of solving a problem for a customer versus producing a series of professional work items that solve the problem and increase customer satisfaction.
Try not to think of a definition of done as a simple checklist and start to see it as an opportunity to help your team become more effective and efficient. An opportunity to capture and create even greater value for both the customer and the organization.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster