Monday Thought: Is it Done?!

From: Murilo Lessa <murilo.lessa@>
Date: Monday, 24 March 2014 17:37
To: Dev All
Subject: Monday Thought: Is it Done?!

In our previous Retro we discussed our Definition of Done (DoD) and we are now in the process of formalising it. The DoD should be a agreed & shared among all teams so I invite you all to take part in this discussion and come up with the bare minimum that we understand as DONE.


Scrum requires Teams to build an increment of product functionality every Sprint that is potentially shippable. To do so, the increment must be a complete slice of the product, additive to all prior increments and thoroughly tested, ensuring that all increments work together.

N Teams, 1 Agreement! 

Asserting that functionality is done might lead someone to assume that it is at least cleanly coded, refactored, unit tested, built,and acceptance tested. Someone else might assume only that the code has been built. If everyone doesn’t know what the DoD is, the other two legs of empirical process control don’t work. When someone describes something as “done”, everyone must understand what “done” means.

Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the DoD does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all PB items in the increment.

That may be too much! No worries! When Teams aren’t yet able to include everything required for implementation in their DoD, this must be clear to the PO. The remaining work will have to be done before the product can be implemented and used.

But we already have a big Code Best Practices document!

The DoD is not a set of best coding practices. You are expected to  be using the Team Best Practices when doing your code but the DoD sits on top of it, at a more business level and is shared among the teams and Product Owners who know what does it mean for a certain story to be Done.

Where to start? Simple as we can. A story is Done when:

  • It has being tested (unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration)
  • It has being documented (code comments, type hints, confluence – if required, etc)
  • It has being pair reviewed
  • It has being validated by QA
  • It has being checked by Product

Is this enough? Is it too much? Keen to hear your thoughts!

Best regards,


This is part of my email experiment - sent every 2 weeks - with the dev team I am part of, aiming to inspire them to acknowledge and question What do we do, Why do we do it, and How do we it.