Definition of Done in Agile

The Definition of Done (DoD) is a description of what must happen for a project or user story to be declared complete. What are those things that must be done to move from “In progress” to “Done”? That’s what the DoD is about. In Scrum teams, the definition of done helps to determine when work can be considered as done on the product increment. It spells out what makes a product increment releasable.

A common and aligned definition of done ensures team expectations are met and that the code performs as expected and that nothing is broken. It drives the quality of work and the assessment of user story completion. The definition of done often takes the form of a checklist. This has a variety of items or steps that can include:

• Acceptance Criteria are met
• Passing code review
• Feature flag incorporated
• Unit testing classes written
• User acceptance testing (UAT) on Staging environment
• Updating user documentation
• Code is checked in and properly merged

Of course, checklists will vary across companies. The constant thing, however, is that a release won’t be deemed ready until all items on one are ticked off.

Components of Definition of Done

In an article on Scrum.org, Sumeet Madan identified three main components of DoD in product development, namely:

• Functional requirements
• Quality
• Non-functional requirements

Functional requirements

These are the regular requirements that help a product to deliver value, coming in form of functionalities. They can be presented as user stories that are usually accompanied by acceptance criteria.

Quality

As earlier stated, DoD is supposed to drive the quality of work. The product development team sees to this component with a view to delivering excellent quality.

According to Madan, quality standards can be driven by data or be subjective. Design principles, Test-Driven Development, and defined coding standards, such as FxCop, are examples.

Non-functional requirements

These are non-core attributes of a product. They may not carry or add direct value but you cannot afford to overlook them. Non-functional requirements have some relationship to quality.

Examples include usability, reliability, compliance, security, and performance.

Why the Definition of Done is Important

DoD can go a long way in promoting transparency in the team. There is a great danger in leaving what it means for a project to be “done” open for any single individual or group to decide. It is almost certain that conflicts would arise at some point and the end-product of such a process will not live up to expectations.

By deciding from the very beginning what constitutes done, you are setting your team up nicely for success. Everyone will have a shared understanding of what is expected out of a process or project. The DoD drives quality fit and improves confidence within the Scrum team.

You can also save precious time and other resources by defining done in advance. It prevents possible slowdowns along the line when you could start struggling to define this. Everyone will more easily know what is expected of them to make things run smoothly.

DoD reduces the chances of pushing out features that don’t quite cut it to users. It also lessens the need to redo things that aren’t as expected or desired. This means it can help in preserving the limited resources at your disposal.

Definition of Done vs. Acceptance Criteria

The DoD might start to sound like the Acceptance Criteria somewhat. Some people may also ask why the former is a thing for product managers to give attention to.

The DoD is at the general level. It applies to and guides everything that an organization is working on to release. However, although it is supposed to apply to everything, a product is hardly ever “done” for product managers.

Product management participates in the definition of done by reviewing the checklist to see if it’s detailed enough. It is usually not responsible for defining what is done.

Product managers are more concerned with the acceptance criteria, which spells out what a product or feature should do satisfactorily. These criteria apply strictly to specific user stories or features.

Product management defines the acceptance criteria. The technical team may chip in on what it takes for a work item to be seen as done.

Defining Done Effectively

Engineering plays a central role in the definition of done in many cases. After all, the DoD aims at ensuring that technical requirements are met. The head of engineering, which often acts as the Scrum Master, commonly leads the definition.

However, the DoD should be a collaborative effort. People carrying out the work and other stakeholders should team up to create the checklist.

Collaboration shouldn’t mean coming up with a very long list of items, though. It is best to keep your DoD as short as possible. Too many items can result in a failure to deliver what measures up to expectations. It may also lead to working on only a portion of the checklist, thereby missing out on the targeted value.

Criteria may be assigned to individual owners. This can help to ensure that everything is well accounted for and can promote consistency.

The definition of done doesn’t necessarily imply that everything on the checklist must be checked off for all work items. Engineering may be given some freedom to determine what is of utmost importance.