When it comes to defining something that is ready or “done” (DoD =definition of done) we always have to take into account the fact that every list of things to be done is different from project to project. Nor is the human staff the same in all projects and the circumstances surrounding those projects equally change. Therefore, there is not an exact Definition of Done on all projects.
It must be made clear that there can be several DoD in a Project. The Dod of functionality, the Dod of a Sprint, etc. In this case we will only focus on the DoD of functionality, as a part of the compliance of a customer’s set of requirements.
There are many examples of DoD, but most of the things we use to find on the internet or in the literature are generic and do not take the real project setting into account. What we want to share in this post is how a set of project implementation of an Enterprise Resource Planning (ERP) as Odoo (although that is valid for almost any kind of technological project) makes evident that such Dod lacks in some aspects to be contextualized. Odoo (aunque es válido a casi cualquier proyecto de tecnología) deja en evidencia que a dichas DoD le falta contextualizar algunos aspectos.
What you are not told to take into account
The formal sources don't tell you about certain numbers of important variables. The DoD's are fuzzy or different for each project. The experience has taught us vital aspects to take into account:
The requirements
Are they really detailed?
Are the Users’ Stories (U.S) well-defined? In other posts, we will make reference to how to establish the criteria of “well-defined”. The most important aspect to highlight is that accuracy of acceptance criteria, assumptions and final conclusions can tell us about a very reasonable approach to reaching an overall suitable Dod for the project.
It is worth recalling that the same acceptance criteria do not include the Definition of Done of functionally or U.S. They only indicate customers’ expectations related to what can happen with the software under certain circumstances.
Customers’ level of commitment
How close are we to know?
The performance of human staff is really vital to establish a clear DoD, which leads us to ask the following question: In what part of the project do we have a proper DoD? It is basically going to depend, in part, on how well the involved actors can know each other in terms of performance. After many projects implementing Odoo, we recommend to consider the following aspects:
Don’t take what they promise you, just make them carry out what they promise you
The “real” level of commitment, and not the professed one, on the part of the Product Owner/ Project Manager on the client side is known when implementing the development process of the software functionality. In many cases, we count on the fact that the customer will give us 5 daily hours of a project manager to validate our deliveries, among other things when we are in full swing, we realize it’s not like we think. And therefore, there’s an important breach of their dedication.
What to do?
First, before starting with the project, let’s suppose that we have the highest level of engagement from that manager or product owner. With that aspect in mind, we formulate the DoD.
Subsequently, evaluate the breach between what we expected in terms of time and dedication on the part of the customer for us when the project is underway.
If a product owner or a project manager has other occupations with the customers it is typical that the kind of dedication can’t be what it was promised. This can be normal; and it MUST be prevented in the event of a person that can’t be committed and dedicated to our project.
That said, the whole situation undeniably affects the economic level of the project, given that there is less dedication from the customer and it affects the activities that DoD has defined. And subsequently, delays in time and budget increases come up.
Some examples of defined activities in some Dod that include direct participation of the customer can be:
Review and approval of the feature by the product owner in the testing server
Video documentation of the feature by the key customer.
Generation of report X from the customer for the validation of results, among other things.
As can be seen, if the customer is delayed, my DoD won’t be fulfilled. And then, inconveniences related to money and time will come up.
In brief, any DoD that has been done before the beginning of the project has to be reviewed for the benefit of the project’s economic health, considering customers’ participation.
Hardware infrastructure
When is not our responsibility but can affect us
Another important aspect regarding software functionality of DoD is the agreement that defines what the Testing and Production platform will be like, and how it will function.
We sometimes have encountered certain situations of starting projects (and even we finish them), and the deployment of production servers from the customer hasn’t still been executed. Therefore, all developed functionalities remain implemented within a Testing or pre-production setting, which theoretically should be one of the intermediate stages of functionality deployment, but in this case, it ends up being the final stage.
Accordingly, if we know that the production setting is not a reality at the beginning of the project, nor will it be in the long term, we must clearly specify in the DoD where we will get the job done: Customers’ testing environment? A Cloud Server from a third party? Local environments? , etc.
Let us remember that the compliance of “Done” depends on the technical/administrative completion of functionality and cannot be attached to deployment delays of infrastructure not stipulated in the project.
The DoD is not an impregnable Checklist
Always can be review it
Even though a list of activities can be defined for a DoD, considering the variability mentioned in the previous sections, we should be aware that one DoD cannot be applicable to all functionalities. The natural definition of “Ready” has certain restrictions if we see it as a mandatory checklist for all developed functionalities.
The development team should be aware of that, and at the same time, understand that some activities must be applied to comply with the checklist and some others must not, depending on what it is implemented.
User's Story DoD example
All associated tasks are finished
Unit tests are approved
Verification of the code standards is OK.
Merge’ s proposal reviewed and approved.
There are no faults to “be checked”
Non-functional requirements were fulfilled.
Acceptance criteria were fulfilled.
The product owner validated the acceptance criteria in the pre-production environment with real data.
The product owner validated things accepted in the pre-production environment now is working in production setup.
