Key takeaways on the idea of Definition of Done:
- According to the Scrum Guide: “The Definition of Done is a formal description of the state of the Increment (a concrete stepping stone toward the Product Goal) 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.”
- DoD’s Role in agile methodologies: in agile, DoD is crucial for maintaining alignment between development teams and stakeholders, ensuring that each sprint or iteration produces fully shippable products.
- Customisation of DoD: the DoD can be tailored to specific projects or teams, evolving over time as the project grows in complexity or as team capabilities change.
- Need help with DoD preparation in your projects? We have over 20 years of experience – get in touch!
What is the Definition of Done (DoD)?
The Definition of Done (DoD) includes the conditions and criteria that a software solution or feature has to meet in order to be accepted by the customer. When something is done – this means that it can be released without any further work or testing.
Of course, DoD varies per project and is something that should be discussed and agreed upon by all parties involved. It depends on a lot of variables, such as the unique processes, goals and setups for a project, and is pretty important in the final stages of software development.
Why? Because DoD helps to prevent technical debt from being unwittingly accumulated and creates a common understanding of what is considered to be done. This helps us avoid a lot of potential conflicts and confusion, or waste too much time overdoing things.
Plus, DoD allows us to maintain control over the development process by making it more predictable and improving the quality of the outcomes.
Find out more about software product development:
- How to create a proof of concept in software development?
- The impact of AI on software development: opportunities and challenges
- Code of ethics in business: benefits, importance and its impact
How does the Definition of Done differ from acceptance criteria?
The Definition of Done (DoD) and acceptance criteria are both important concepts in project management and software development, but they serve different purposes and operate at different levels. Here’s how they differ:
Definition of Done is a set of general, overarching criteria that apply to all work items or user stories in a project. It represents a shared understanding within the team of what it means for any piece of work to be considered complete. The DoD typically includes standard quality measures, testing requirements, and documentation needs that are applicable across the board.
Acceptance criteria, on the other hand, are specific to individual user stories or features. They define the particular conditions that must be met for a single item to be considered satisfactory and accepted by the product owner or stakeholders. These criteria are usually more detailed and focused on the functionality and behavior of the specific feature being developed.
While the DoD ensures a baseline level of quality and completeness for all work, acceptance criteria ensure that each individual feature meets its intended purpose and satisfies user needs. The DoD is generally created and agreed upon by the entire scrum team and remains relatively stable throughout the project, whereas acceptance criteria are typically defined by the product owner or business analyst for each user story and can vary greatly from one story to another.
How to define Definition of Done in software development?
If you want to define what it means for something to be done – there are 3 steps to follow:
- Create a general Definition of Done for your company that can be applied to any project.
This will help you clarify more specific criteria later on, whenever a new project is about to begin. For example: “The code has been written, documented and reviewed. The code works – it has been tested and doesn’t break anything along the way”. A broad statement like this is a good starting point for the next step, allowing you to work on your DoD in the right order, from general to specific. - Create detailed checklists for your team.
Every checklist has to cover a different area of software development, so it’s important to assign all the specific points to the right categories. The checklists have to be clear for everyone involved and adjusted to each project. However, you will quickly discover that the vast majority of points can be reused over and over again. Once you have the basics covered, it’s always easier to define “done” for other projects, too. - Check your DoD against the project goals, requirements and values.
DoD always has to be in line with your client’s needs, which is why it needs to be verified. This way, you can be sure that you will deliver to your client’s expectations, which is the most important criteria for success.
And please note that the Definition of Done shouldn’t be forced upon. It is quite the opposite – the best way to come up with DoD for your Scrum team (including Product Owner, Quality Assurance specialists, and developers) is to sit and figure this out together.
You will find many additional tips and hints in the related articles:
- The power of requirements workshop: revolutionising project planning
- Requirements Engineering: choose the workshop that best suits your needs
- Creative techniques in the requirements elicitation process
Who is responsible for creating the Definition of Done?
The creation of the Definition of Done (DoD) is typically a collaborative effort involving multiple stakeholders, but the primary responsibility often lies with the development team and the Scrum Master in Agile environments.
The development team, being the ones who will ultimately execute the work, plays a crucial role in defining what “done” means from a technical and quality perspective. They bring their expertise and understanding of the development process to ensure the DoD is comprehensive and achievable.
The Scrum Master facilitates this process, ensuring that all necessary perspectives are considered and that the DoD aligns with Agile principles and organisational standards. Product Owners also contribute by representing the business and customer perspective, ensuring that the DoD includes criteria that meet stakeholder expectations.
In some companies, management or senior technical leads may provide input to ensure the DoD aligns with company-wide quality standards or regulatory requirements. Quality Assurance teams might also be involved to incorporate necessary testing and validation criteria.
It’s important to note that while these roles contribute to creating the DoD, it should be a consensus-driven process. The entire team needs to agree on and commit to the DoD for it to be effective. Once established, the DoD isn’t set in stone; it should be reviewed and refined periodically as part of the team’s continuous improvement efforts.
The areas that need to be covered in a Definition of Done?
There are a few areas that certainly need to be addressed whenever you are preparing checklists for your team. You have to ask yourselves a number of questions in order to make sure the lists are comprehensive, without involving any unnecessary conditions or creating additional acceptance criteria.
Try to keep it simple and don’t overcomplicate the process – but don’t allow yourself to overlook anything either.
To get an idea of which areas should be covered and what kinds of questions should be asked, look at the examples below:
Area: Development
- Is the code enough or do we need to write the tests as well?
- What kind of tests do we need to write?
- Do we need to test everything or just a few selected areas of development?
- Do we need to have a code review?
- Who should do the code review?
- Do we need documentation?
Area: Testing
- Do we need to test this feature?
- What kind of tests do we need to run?
- What exactly should be automated in the tests?
- Can we leave any specific bugs?
Area: Continuous Integration/Deployment
- Do we need to validate changes by creating a build and running automated tests?
- Do we need to run static code analysis?
- Do we need to deploy this feature to certain environments?
DoD: the checklist
Once you have all the answers that you need, it’s time to prepare the developer’s checklists. These should include clear, concise and very specific points that are totally unambiguous so that they don’t create any confusion.
Those checklists may include points such as:
- Unit tests have been created.
- Code Review is done; conditions:
– 2 developers need to accept the pull request,
– at least one senior developer needs to accept the pull request. - The user story has been tested by quality assurance.
- There are no high severity bugs linked to that story.
- Automated tests have been created, if applicable.
- Backlog items have been verified in the Test environment (including non-functional requirements, etc.).
- Product owner review is complete.
- Code has been implemented according to the technical concept.
- Acceptance criteria have been fulfilled.
- US code is “non-breakable” (rollback is possible).
- UX check is done.
- [If required] automated tests have been implemented – GUI tests, contract tests.
- [If required] non-functional tests have been completed – performance tests, security tests.
As you can see, these points are crystal clear and leave no room for any confusion. Every team member will understand them in the exact same way, so whenever a piece of software or feature is considered to be done – it’s indisputable.
Contact us
Looking for help with software development? Bet on more than 20 years of experience!
What are the benefits of having a clear Definition of Done?
Having a clear Definition of Done (DoD) offers numerous benefits to project teams, stakeholders, and organisations as a whole. Here’s an overview of the key advantages:
A clear DoD ensures consistency in quality across all deliverables. It sets a standard that every team member understands and works towards, reducing variability in the output and maintaining a uniform level of quality throughout the project. It aids in accurate sprint planning and estimation also- when team members have a clear understanding of all the steps required to complete a task, they can provide more accurate time and effort estimates.
It improves team communication and alignment. With a shared understanding of what “done” means, team members can work more effectively together, reducing misunderstandings and conflicts about the expected level of completeness for tasks.
A well-defined DoD helps in managing stakeholder expectations. It provides clarity on what will be delivered, helping to avoid situations where stakeholders might have different ideas about what constitutes a finished product.
It aids in accurate sprint planning and estimation. When team members have a clear understanding of all the steps required to complete a task, they can provide more accurate time and effort estimates.
A clear DoD reduces the accumulation of technical debt. By ensuring that all necessary steps (including testing, documentation, and code review) are completed before considering work done, it prevents the buildup of unfinished or substandard work that could create problems later.
A DoD can help in regulatory compliance. In industries with strict regulatory requirements, the DoD can incorporate necessary compliance checks, ensuring that all work meets regulatory standards.
What happens if work doesn’t meet the Definition of Done?
When work doesn’t meet the Definition of Done (DoD), it’s generally not considered complete and shouldn’t be accepted as finished. In Agile methodologies, particularly Scrum, this work is typically not counted as part of the sprint’s completed work and doesn’t contribute to the team’s velocity.
The immediate consequence is that the work item or user story remains incomplete and is usually carried over to the next sprint or iteration. This can impact the team’s ability to meet sprint goals and may affect overall project timelines. It’s crucial for the team to address why the work didn’t meet the DoD and take steps to rectify the situation.
The Definition of Done is a tool that you should use to maintain full control over the development process; it helps reduce the risk of prematurely releasing something that is not quite ready to be presented at your next Sprint Review — or to your client.
When defining what “done” is, you should always follow a few good practices:
- Go from general to specific.
- Keep things clear and simple.
- Make your definition as comprehensive as possible.
- Don’t overcomplicate things.
- Bear in mind your client’s needs and expectations.
This is probably the simplest guide to the Definition of Done that we can give you. If you still have any questions or doubts – don’t hesitate and contact us, so that we can be of assistance!
Developing software products is what we’ve done for over 20 years Capitalise on our expertise in software development and turn your idea into a great product! Let’s talk!
