During the early days of my Scrum journey, the Definition of ‘Done’( DoD) was one of the concepts that gave me some headaches. This article is to explore this topic and discuss some of the Anti-patterns I have experienced.

Definition of ‘Done’ provides a shared understanding among Creators of the product/service -(The Scrum Team- Developers, Product Owner, Scrum Master) and Inspectors (the stakeholders). It defines what it means for the work to be usable and complete. It is the commitment for the Increment.

Aim of a Sprint is to create ‘Done’ potentially releasable increment. Hence having a Definition of ‘Done’ is a crucial element of the Scrum framework. It supports empiricism by providing transparency via building a shared understanding of what elements are required during development to convert a Product Backlog Item into a potentially releasable Increment.

Who is Responsible:  Definition of ‘Done’ requires collaboration from entire Scrum Team. As Product Owner is closer to customers/market, they bring important quality criteria that customers expect. Developers bring key quality criteria for technical standards, architecture and process. However, if there are some organisational level norms then teams must adopt those as the minimum and expand whenever needed. 

Definition of ‘Done’ in relation with 5 Scrum Events

The Definition of ‘Done’ supports the Scrum framework throughout the Scrum framework. It supports all the 5 Scrum Events.

Sprint Planning: Definition of ‘Done’ helps the team in selecting the amount of work that can be pulled from the Product Backlog. Based on this a team can estimate how much effort it will take to convert a product backlog item into a done increment.

For example: If product’s Definition of Done includes ‘Creation of Release Notes’. It will require sometime for the Developers to create/verify/publish Release Notes, hence Developers need to this activity as part of their planning.

Tip: It is highly advisable to make the Definition of ‘Done’ visible throughout the Sprint Planning.

Sprint: During the development work, the Definition of ‘Done’ guides the team by helping them identify tasks that were missed in the Sprint Planning but need to be completed.

Daily Scrum: Definition of ‘Done’ helps teams to realise that even if an individual member(s) has completed his/her tasks related to a product backlog item, but that item will not be considered as ‘Done’ until the definition is met altogether. It help builds ‘team goal over individual goal’ mindset.

Sprint Review: It provides a shared understanding between Stakeholders and the Scrum team about what ‘Done’ means. It enhances transparency and supports empiricism. This transparency helps in inspecting the product increment and directing the future direction of the product.

Sprint Retrospective: This is key event where the Definition of ‘Done’ gets adapted to improve product quality. Many teams start with a less stringent Definition of ‘Done’. However, the long term goal should be to reduce the technical debt that could be accumulated because of less stringent Definition of ‘Done’.

Not having a good Definition of ‘Done’ or not following it is one of the main reasons for the poor quality of the product and accumulating technical debt. This reduces the sustainability and scalability of the product in the long run. Sometimes this inability to sustain and scale cripples organisations.

Caution: Teams/Organisations should respect the fact that it takes effort and time to reach to an optimal Definition of ‘Done’. It will vary for different products. Teams need to apply regular inspection and adaptation to get better at it. Simply ‘copy and paste’ might not work.

Anti Patterns

Below are a few key Anti-patterns I have observed in my experience and have tried to describe how to overcome-

1) Not having a practical & pragmatic Definition of ‘Done’– One of the key root cause for not having or following a Definition of ‘Done’ is that- ‘it is not being practical and pragmatic in that moment of time’. Many organisations/teams adopt a Definition of ‘Done’ which is hard or in many ways impossible to achieve in the first few sprints. This leads to a belief that it is optional and ultimately, the essence of scrum is lost.

Tip: To overcome this, it is better to start with a less stringent Definition of ‘Done’ which is practical and achievable by the skills available in the Scrum team. Team can learn ways of working quickly and improve on Definition of ‘Done’ later. Key here is to craft a Definition of ‘Done’, which is actionable in that moment of time.

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality”- Scrum Guide.

Caution: Try to quickly extend the Definition of ‘Done’ otherwise team will start accumulating the technical debt which will be very difficult to repay.

2) Not Inspecting and Adapting- Another common mistake that organisations/teams make is by not inspecting and adapting the Definition of ‘Done’ regularly. As Geoff Watts quoted in his book Scrum Mastery

A good Scrum Master help the team to meet the Definition of ‘Done’ at the end of the Sprint. A Great Scrum Master help the team to extend their Definition of ‘Done’. — By Geoff Watts- Scrum Mastery.

Inspection & Adaptation is core to the Scrum framework and this applies to the Definition of ‘Done’ as well. During the Sprint Retrospective, teams should adapt the Definition of ‘Done’ based on their own experience during the Sprint and the feedback received during the Sprint Review.

Tip: Make Definition of Done as a must topic for Sprint Retrospective. Ask few questions, such as: What could be added/changed to the current Definition of Done to improve quality/process? Few ideas can be- Code reviews, Automation, Release Notes, No known defects etc.

3) Scrum-falls- Teams that are new to the scrum, sometimes fall into a trap where they tend to complete only some part of the work related to a product backlog item rather than finishing the entire work. There is not enough emphasis on ‘Done’ or team doesn’t work as a single unit.

For example- If Coding and testing are only tasks associated with product backlog item A & B, they plan like below:

Sprint 1: Code A

Sprint 2. Code B, Test A.

This is NOT Scrum. The team should find out ways how they can Test A within Sprint 1. Scrum master’s role here is to encourage the team to explore new ways and building the habit of creating ‘Done’ increments.

‘Done’ is binary. Either it is ‘Done’ or ‘Not Done’. There is nothing like partially done, my part done, 90% done etc.”

Tip: Sometimes teams can’t deliver ‘Done’ increment because product backlog items are too big. Teams can benefit from decomposing such items. Refinement can help.

4) Single Product-Multiple Teams but Different Definition of ‘Done’: In many cases, multiple teams work on the same product. In such scenarios, having different Definitions of ‘Done’ can create integration issues and sometimes chaos.

Definition of ‘Done’ is for the product increment and in case of single product-multiple teams scenario, this must apply to the integrated product increment.

Tip: When multiple teams working on a single product, teams should adopt a common Definition of ‘Done’ for their combined Product Increment. If teams have not integrated their work by end of the Sprint, it should not be considered as ‘Done’.

End-Note: Definition of ‘Done’ increases transparency in the Scrum framework. It builds a shared understanding across all interesting parties. It also helps in building Self-organisations in the team. But it is not static. It is dynamic that gets better over time.