• 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.

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

And once you’ve chosen a solid technology partner to work with, there are a number of things that you can expect from them on a regular basis. The items listed below help distinguish great partners from those that are merely competent.

7 things to expect from your IT partner

1. They are focused entirely on your project

Even though your partner may be a big organisation serving many clients at the same time – you will have a team of experts dedicated solely to your project, fully focused on delivering value and working up to your expectations. You will know it’s a good company, if they take their time to deeply understand your business needs and requirements during the early stages of cooperation.

This way, the outcome has a better chance of being useful for you, your employers or customers, depending on who the end users are.

2. Their working routine is well-structured

When you start a cooperation with an external partner, you can expect well-organised processes and a basic outline of the work to be delivered in the long run. You know what hours people work, the best time to contact them, and when the desired outcomes will be delivered to you (e.g., every two weeks, once per quarter or no sooner than after a year of cooperation).

Moreover, their scheduled meetings are consistent with their fixed agendas, so you know exactly who should be participating. There’s always time to report impediments or project blockers in a scheduled meeting, or to have a discussion about the way they work and how they can optimise the process, which fosters transparency.

3. They practice transparent communication

Openness and honesty are two values that are absolutely indispensable on a daily basis; they keep the project on track and push the work forward in the right direction.

Transparent communication should go both ways and be rooted in having good and efficient language skills – in the official language that you chose for your project. This may sound obvious but in software outsourcing – and especially when offshoring to a distant country – the reality may surprise you. That’s why it is so important to check the language skills of the key people who will be involved in the cooperation process, and not only the people who are signing the deal.

Plus, you may expect that you will be notified of any issues or opportunities that appear along the way. A solid partner won’t hide anything from you.

4. They take a proactive approach

This is strongly associated with seizing opportunities and preventing potential problems from turning into serious issues. Your IT partner will keep their eyes open for anything that could be beneficial to your project, like new technologies, business options or emerging and promising trends.

They won’t wait for you to take initiative – that is what an average supplier would do. If you bet on the right software company – a true technology partner – their proactive approach will allow you to achieve and maintain a competitive edge.

5.They also pay attention to non-functional requirements

It’s not just about the specific functions of your software. The list of non-functional requirements (NFR) that a solid company will deal with on a regular basis is also pretty impressive, and you may expect to have everything covered.

NFRs pertain to how your system should operate, rather than what it should do and can apply to, for example:

• security,
• efficiency,
• scalability,
• readability,
• compliance,
• documentation,
• stability,
• response time, etc.

There are many things to consider along the way, and a good partner will ask you about your priorities and what you want to achieve. They will also have their own suggestions regarding the most important aspects of your project and what NFRs should be the center of attention.

6. They provide you with regular updates

In order to maintain control over your project, you will need to receive regular updates from the development team – as often and as detailed as you like. A reliable and transparent partner will also provide you with permanent access to general progress updates for the project in order to keep you and your stakeholders informed.

This way, everyone knows where they stand: what has been done, what has to be changed, what lies ahead, and so on. This kind of approach is good for both sides of the cooperation, because it fosters transparency and prevents chaos.

7. They help you flexibly adjust to the changing environment

Potential changes in the world around us can appear out of nowhere and pertain to virtually every part of your business environment, and this can have a negative effect on your processes. The concept of VUCA – the volatility, uncertainty, complexity and ambiguity of situations that occur nowadays – is still valid today, even though it is over 30 years old. For example, there may be a total shift in the political situation and business regulations (e.g., due to a pandemic) making it necessary for everyone to change the way they work, literally overnight.

How your partner handles these kinds of issues will prove their competence. You may expect that a good company will quickly and flexibly adjust to the changing environment and guide you through even the most demanding situation as flawlessly as possible.

Wrap-up

These are all pretty important things to consider, at least in our opinion, and you should definitely think about how to include them in your RFP process. The right IT partner shows you the way to success in the field of technology. Your day-to-day collaboration is nothing to be afraid of – they’ve got you covered and, in the end, they will deliver the expected outcomes. But, of course, project success depends on your approach as well. Open-mindedness, responsiveness, high levels of engagement, transparency, and adherence to following procedures that everyone has agreed upon are required from both sides of the cooperation. This is how a beneficial and long-term partnership is created.

Are you looking for the IT Outsourcing Partner? Check our downloadable 100% free RFP template and make sure you choose the best one!