Project management in the technological field is a key element for the success of the operation since it lays the foundations and general structure of the project to be carried out, since the other elements are built on this structure, such as the design of the interface, user experience, concept validation, quality tests, among others.
For these projects to progress, we must first understand their purpose, as well as the current, future, explicit and implicit needs of our clients, their end-users, and the respective stakeholders. Subsequently, and understanding the scope of the solution, we divided the project into phases that allow us to carry it out in an agile and efficient way.
This is where the difficulty comes since we must strategically assign each activity to be carried out, understanding that we must complete one to continue with the next, however, the question constantly arises: is this task/activity “done”? Is it not related to another future task that may affect your status?
These and other questions are the most common of the thought, being the main debate that both the client (Product Owner) and the project leaders should have on the part of the software development companies.
Define the meaning of “Done”
The Definition of “Done” is when all the conditions, or acceptance criteria, that a software product must satisfy are fulfilled, so that it functionally meets the requirements of a user, client, team, or is available for use by Another system, complying with the established quality parameters. This prevents any incomplete feature/functionality from being put into production, generating errors, and rework when having to return to make the correct corrections, as well as dissatisfaction from customers and/or end-users.
This definition is determined at the beginning of each project, usually in the meetings held by the Product Owner and development leaders, however, it usually happens that as the project progresses, this definition is restated several times, so that the expectations of the same end up coupling to the practice, as well as to the different parameters of quality, work process, among others.
Having clear when a feature/functionality is “done”, then you can get a better idea of where we are in the project, allowing us to make more accurate and clear decisions about how much to complete and when the respective resources should be included in the project.
A key element, which will help us enormously in this definition, consists of the so-called User stories, these could be defined as the path that users follow within our development to carry out the desired tasks.
One of the biggest risks that can occur from not having a clear definition and understanding of the parts occurs precisely when presenting all the requirements completed during the project, precisely at the end of each iteration, where at the moment we make the necessary reviews we will realize that these requirements are not completely finalized, generating debates on real progress.
The importance of agreeing terms
When a user story or an increment (set of stories) is “Done”, everyone on the team should understand the same thing: that this functionality/increment can now go into production. Although this understanding is the result of transparency and trust between the parties, the most evident part is when you usually advance to the next phase of the project, for example: when the Scrum team finishes a sprint.
Another important aspect is to define how to complete a feature, functionality, story, or increment must be to move to the next stage. If this is of vital importance for the entire project, then it should be considered as a minimum criterion. Otherwise, part and part misunderstandings will occur again.
However, the definition of “Done” may evolve. When the relationship between the Product Owner and the Scrum team matures and develops positively, it may happen that the definition of “Done” previously used in the increments is expanded during the Retrospective and feedback meetings, including new criteria of higher quality, based on more practical parameters.
Relationship between “Done” and Acceptance Criteria
An important element to determine the status of some features, functionality, etc. It is the so-called Acceptance Criteria, its most basic definition is when it meets all the minimum requirements necessary to be able to be put into production, both on a technical and functional and operational level, among others.
The acceptance criteria are important for:
- Manage expectations, both for the Product Owner and for the Scrum team.
- Define scope and reduce ambiguity.
- Establish test criteria for quality control.
- Avoid scope change in the middle of the Sprint, which directly affects planning.
Use of the Definition of “Done” in the Phases of a Project
Once this definition is understood, as well as the minimum Acceptance Criteria, those responsible for planning the project will be able to prepare the appropriate sheet/roadmap for the development of the product/service, as well as the global estimate of the effort to invest in order to comply effectively with User Stories.
In turn, it defines the amount of work to be defined in each Sprint, since it will be used as a guide to comply with the definition of the criteria established in the planning meeting and in the subsequent follow-up and retrospective meetings. This results in better evidence at the completion of one phase of the project and the start of the next.
Impacts of the lack or misapplication of the Definition of “Done”
One of the main effects of an incomplete or misapplication of the Definition of “Done” is “Technical Debt, which refers to the additional work produced by an implementation of functionality or feature that was not completed, or that did not comply with all the minimum necessary requirements, such as having carried out the appropriate quality tests, or documentation.
As a main consequence, we find that the team must rework to finalize the minimum requirements in the previously approved functional / characteristics, which generates delays and loss of resources.
Tips to keep in mind when writing the Definition of “Done”
- Involve the team: include in the planning stage the largest number of responsible team members, in this way everyone will be able to give their point of view and bring to the table topics that only could be seen later in the project. Improving the vision of the project and when one phase would end and another would begin.
- Perform user stories: This valuable resource allows us to identify user needs from their point of view. The better defined they are, the easier it will be to determine when development is “Done”.
- Comply with the technical requirements: it is very important that all the functionalities and technical requirements are met, so that the development has the accepted quality parameters, guaranteeing that the application has the expected performance.
- Compliance with requirements: It is very important that all the functionalities and requirements are reached at a technical level, so that the development has the accepted quality parameters, guaranteeing that the application has the performance expected.
- Execute functional and non-functional Testing: Validating the quality and that the technical requirements are properly tested is key. No development of any kind should be considered “Done” without having gone through the Testing & QA process.
- Contemplate the Epics: where “Done” at this level can refer to a strategic priority of the organization, an objective of the business plan, or some set of requirements that satisfy a market need.
The art of managing a project goes beyond dividing it into phases and allocating resources and delivery dates, the most important thing being to thoroughly understand both the client’s requirements and to have the technical domain necessary to know how to allocate resources correctly.
Huenei’s processes included in its Agile Services Proposal include agreeing with its clients on the Definition of “Done” for their services, allowing transparency in the results and confidence in the progress of the work.
Likewise and as part of the commitment in the application of Our Values of Customer Orientation and Efficiency, we monitor and carry out performance effectiveness metrics of our teams by measuring the level of rework due to deficiencies in the application of the Definition of “Done” and its acceptance criteria.
In terms of carrying out tasks, the key is for the entire team (both internal and on behalf of the client) to be in tune and understand what is needed for software development, feature, and functionality to be fully completed, allowing progress to be made with the project like to raise the flag to indicate that something is missing.