DONE Understanding of “Definition of DONE”

The Professional Scrum Master (PSM-I) workshop has a module that talks about DoD and Technical Debt, and I have often come across students who are confused about this concept. This article is a small attempt to have more clarity on these topics.

Let's take DoD first As stated in Scrum Guide, the Definition of DONE (DoD) is – The Definition of Done is a formal description of the state of the Increment 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. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

In short, DoD is a shared understanding within the Scrum Team on making your Product Increment releasable.

DONE = Releasable

Everything in this universe that is meant for delivery has DoD

• What it takes for the Rocket to launch?
• What does the service engineer take to call the customer to deliver the vehicle?
• What it takes for the Doctor to say, "The Surgery is a Success"?
• What does it take for the Development Team to put the Product into Production?

and so on…. When we talk about Product Development (considering the system/software/solution), the DoD consists of 2 main components:

• The Requirements – Build the right Product, or its functionality
  • Business or Functional requirements
  • Non-Functional Requirements
• Quality – Build the Product right
  • Maybe the defined quality standards at an organizational level
  • Best practices

Business or Functional requirements

The business requirements assumed to carry value in the Product as functionality may be written in the form of User Stories and has the acceptance criteria.Example:

Non-Functional Requirements

These are the quality characteristics or attributes of the Product that may not add direct business value but without which your Product can't move. These quality assurance attributes of the Product can also be considered under the quality component.

Example:

• Availability
• Maintainability
• Performance
• Reliability
• Scalability
• Security
• Usability
• Compliance/Regulatory
• Legal

NFRs usually take their place in acceptance criteria or the Product Backlog as Product Backlog Item (requirement)  but are the key for Product success and hence are part of the DoD too.

Quality and/or best practices

Quality is more aligned with the coding language or RAD/technical tools to build the Product. The developer owns the quality to ensure the Product is of the maximum quality. These quality standards can be subjective and data-driven.

Example:

• Defined coding standards (like identified in tools – FxCop etc..)
• Test Driven Development
• Unit Test Coverage
• Maintainability Index
• No Defects or no known defects
• Technical Debt
• Design principles

and so on… The Definition of Done for an increment is usually part of the organization's standards. If it is defined at the organization level, then all Scrum Teams must follow it at a minimum, but if not, the Scrum Team must create a Definition of Done appropriate for the Product. The Product Owner can influence the Definition of DONE, but the Scrum team has the final say on this. A few examples of DoDs (New to Mature and Stringent)

FAQs on DoD – Definition of DONE

Do we need everything as part of DoD?

Well, it depends on the nature of the Product's business, but the Definition of DONE concludes the Increment as potentially releasable. Therefore, whatever it takes to make an Increment releasable must be included as criteria in the DoD.

Do we need to have all these parameters from the first Sprint?

Well, the Product evolves as we learn more about it, its usage, and the competition. With the evolving Product, it's a mandate to ensure the quality and the user experience. It may so happen that the Scrum Team(s) starts with a LEAN DoD, and then DoD evolves as the Product evolve, and more is learnt.

Do we need to have DoD at the Product Level, Sprint Level, or Story Level?

Well, the moment a Product Backlog item meets the Definition of Done, an Increment is born, and it's the Product or its features that get released to the market or end users; hence, the DoD is at the increments level of the Product.

But as we are working with Sprints, every Sprint must create a releasable Increment of Product, and this means the DoD needs to be met every Sprint to make the Product Increment releasable.

The user stories are part of your Sprint deliverables, so to make every story releasable (functional releases) as part of the Product, that must meet the DoD of the Product.

If multiple Scrum Teams are working on the same Product, then this may so happen that each Scrum team has its own DoD, but the combined or the integrated work of all the Scrum Teams must meet the DoD of the Product, which means their combined/integrated work must be releasable.

How does DoD raise transparency within the Scrum Team?

Well, DoD is a shared understanding within the Scrum team on what DONE Increment of Product means, increasing transparency in the Scrum Team. But, if we consider the DoD as just a checklist for the Developers to complete their work, then this may be barely a checklist document for the sake of having it, and this type of DoD hardly evolves or is refined.

This results in low confidence within the Scrum team to declare a Product as DONE/RELEASABLE, and this also makes the Increment of low quality and non-releasable with a pile-up of UNDONE work.

What is the impact if DoD is not defined?

Well, there is no transparency on if a Product increment is releasable, there is an impact on the estimations or leads to unrealistic estimates, inaccurate forecast on Sprint work, the difficulty for the Product Owner to understand the progress on the Product, inefficient inspection and adaptation at Sprint Review and finally, the DoD can impact Product's total cost of ownership.

What is UNDONE in the context of DoD?

Well, UNDONE work refers to anything that is not completed, as mentioned in the DoD, to create a releasable Increment. 

What is the difference between a shippable and a releasable Increment of the Product?

Well, shippable refers to some undone work (mostly related to approvals) stopping the Product Increment from being released to the market. So Shippable is like Almost DONE, which can be referred to as the Definition of Almost Done (DoAD).

It's like we are DONE with the work, but the work is pending approval from UAT or Compliance or Legal, or some Documentation is pending. So in this scenario, your Product is not releasable, but the team refers to that as shippable.

This is also popularly known as DONE (Shippable) and DONE (Releasable). So I mean to refer to your work as "DONE" or "DONE DONE", where the first is referred to as Shippable and the latter as Releasable.

Many definitions of "Done" focus only on development activities, where such activities hold no guarantee of high quality.