Professional Scrum Master (PSM-I) workshop has a module that talks about the Definition of DONE (DoD) and Technical Debt. I have often come across several students who find this concept confusing. This article is a small attempt to have better clarity on these topics. Let us take a look at the DoD-
As stated in Scrum Guides the Definition of Done (DoD) is –
When a Product Backlog item or an Increment is described as “Done”, one must understand what ‘Done’ means. Although this may vary significantly for every Scrum Team, members must have a shared understanding of what it means for work to be completed and to ensure transparency. This is the definition of ‘Done’ for the Scrum Team and it is used to assess when work is complete on the product Increment
In short, DoD is a shared understanding within the Scrum Team on what it takes to make your Product Increment releasable.
DONE = Releasable
It wouldn’t be an exaggeration in telling that everything in this universe that is meant for delivery will have DoD. Let us take a look at the below questions-
- What does it take for the Rocket to launch?
- What does it take for the service engineer to call the customer for the delivery of his/her vehicle?
- What does it take for a Doctor to say ‘The Surgery is a Success?’
- What does it take for the Development team to put the Product into Production?
and many more questions that come across in our day to day lives.
Specifically, when we talk about Product Development (considering the system/software/solution), the DoD consists of 3 main components:
- Business or Functional requirements
- Quality
- Non-Functional Requirements
Business or Functional requirements
This is the standard business requirement that is assumed to carry value in the Product as functionality and this can also be written in the form of User Stories and it carries acceptance criteria as well.
Example:
Quality
Quality is largely aligned to the coding language/Rapid Application Development (RAD)/technical tools to build the Product. Quality is owned by the Development team to ensure that the product is of the maximum quality. These quality standards can be subjective, and also data-driven.
Example:
- Defined coding standards (like identified in tools – FxCop etc)
- Test- Driven Development
- Unit Test Coverage
- Maintainability Index
- No Defects/Known Defects
- Technical Debt
- Design Principles etc.
Non-Functional Requirements
These are the standard characteristics or attributes of the Product that might not add direct business value but without which your Product can’t move. These quality assurance attributes of the Product can be considered under the quality component too.
Example:
- Availability
- Maintainability
- Performance
- Reliability
- Scalability
- Security
- Usability
- Compliance/Regulatory
- Legal
Non- Functional Requirements (NFR)s usually take their place in Acceptance Criteria or the Product Backlog as Product Backlog Item (requirement). These are also the key to Product success and hence are part of the DoD too.
Few Example of DoDs (New to Mature and Stringent)
FAQ’s on DoD – Definition of DONE
Do we need everything as a part of DoD?
It depends on the nature of the business that the Product is dealing with.
Do we need to have all these parameters from the first Sprint?
Since the product evolves over a period and so do the requirements, it can’t be definitive whether we need all the parameters from Sprint 1. Initially, the team starts with the lean DoD and evolves along with the product and is a more learned approach.
Where do we need to have the DoD? Is it at the Product Level/Sprint Level/Story Level?
Because it is the product that gets released to the market, the DoD is always at the Product level.
Meanwhile, since we are working with Sprints, every Sprint must create a releasable Increment of Product and this means that the DoD needs to be met every Sprint to make the Product releasable. The user stories are part of your Sprint deliverables, so to make every story releasable (functional releases) as part of the Product, it must meet the DoD of the Product.
If multiple Scrum teams are working on the same product, then there are chances of each Scrum team having their own DoD. However, the integrated work of all the Scrum Teams put together must meet the DoD of the Product, which means their combined/integrated work must be releasable.
How does DoD help in increasing transparency within the Scrum Team?
DoD is a shared understanding with-in the Scrum team on what DONE increment of Product means and this increases (raises) transparency in the team.
Whereas, if we consider the DoD as a plain checklist for the development team to complete their work, this might end up being a mere checklist document for the sake of having it and this type of DoD hardly evolve or refine which results in low confidence with-in the Scrum team to declare a Product as DONE/RELEASABLE and this also make Increment of low quality and non-releasable with pile-up of UNDONE work.
What is the impact if the Definition of DONE (DoD) is not defined?
There is no transparency if a Product increment is releasable, impact on estimations or unrealistic estimates, inaccurate forecast on Sprint work, difficult for the Product Owner to understand the progress on the Product, inefficient inspection and adaptation at Sprint Review
What is UNDONE in context with DoD?
Any work mentioned in the DOD that is required to create a releasable increment; however is not completed is referred to as UNDONE.
What is the difference between shippable and releasable Increment of the Product?
Shippable refers to some undone work (mostly related to approvals) which eventually stops the Product Increment release into the market. Therefore, Shippable is like Almost DONE, which can be referred to as Definition of Almost Done (DoAD). In simpler words, it could be understood as, when we are DONE with the work, whereas the approval is pending from User Acceptance Testing (UAT)/Compliance/Legal/ because of any pending documentation.
In this kind of a scenario, your Product is not releasable, but the team refers to this as shippable, popularly known as DONE (Shippable) DONE (Releasable). Whenever we ask, is your work “DONE” or “DONE DONE”, the first one is referred to as Shippable and the later one is referred to as Releasable.
PS: Several definitions of ‘Done’ focus only on development activities. However, such activities in themselves hold no guarantee of high quality.