Project management in the technological field is a key element for the success of any operation, since it lays the foundations and general structure of the project to be carried out. Management is important because other elements are built on this structure, such as interface design, 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 considering the scope of the solution, we split the project into phases that we are able to carry it out in an agile and efficient way.
This is where the difficulty comes in, since we must strategically allocate each activity, understanding that we must complete one to continue with the next. Therefore a question constantly arises: is this task/activity Done? Is it not related to another future task that may affect its state?
These and other questions are highly recurring, being the main discussion that both the client (Product Owner) and the project leaders should have on the part of the software development companies.
Defining the meaning of Done
Definition of Done (DoD) is the understanding that all conditions, or acceptance criteria, that a software product must satisfy have been fulfilled, so that its functionally meets the requirements of a user, client, team, or is available for use by another system, complying with the set quality standards. This prevents any incomplete feature/functionality from being put into production, generating errors and the need for rework, as well as dissatisfaction among customers and/or end-users.
This definition is set at the beginning of each project, usually during meetings held by the Product Owner and development leaders. However, as the project progresses, the definition usually needs to be modified several times so that expectations match practice, quality standards, work processes, etc.
Understanding when a feature/functionality is Done helps us get a better idea of where a project is at, allowing us to make more accurate and clear decisions about how much is to be completed and when the respective resources should be included in the project.
A key element, which helps 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 of not having a clear definition and understanding of the parts can arise precisely when presenting all the requirements completed during the project, at the end of each iteration, if requirements are not fully met at the time of the final revision. This would give way to discussions around the real progress of the project.
The importance of agreeing on the terms
When a user story or an increment (set of stories) is Done, everyone on the team should understand the same thing: this functionality/increment can now go into production. Although this understanding is the result of transparency and trust between the parties, the most evident stage is when we move on to the next phase of the project, for example: when the Scrum team finishes a sprint.
Another important aspect to define is how to complete a feature, functionality, story, or increment 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, misunderstandings may occur again.
However, the definition of Done may evolve. As the relationship between the Product Owner and the Scrum team matures and develops positively, the old definition of Done may be 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. is the so-called Acceptance Critera. Basically, it involves all the minimum requirements necessary to move on to production, on a technical, functional and operational level, among others.
The acceptance criteria are important for:
- Managing expectations, both for the Product Owner and for the Scrum team.
- Defining scope and reducing ambiguity.
- Setting test criteria for quality control.
- Avoiding scope changes in the middle of the Sprint, which would directly affect planning.
Use of the Definition of Done in the phases of a project
Once this definition and the minimum Acceptance Criteria are understood, 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 a global estimate for the efforts to be invested in order to comply effectively with User Stories.
This process also sets the amount of work to be defined in each Sprint, since this will be used as a guide to meet the criteria set during the planning meeting and the subsequent follow-up and retrospective meetings. This results in better evidence upon completion of each 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 the implementation of a functionality or feature that was not completed, or that did not comply with all the minimum criteria, such as the appropriate quality tests, or documentation.
As a main consequence, teams must rework to finalize the minimum requirements in the previously approved function/characteristic, which creates delays and loss of resources.
Tips to keep in mind when writing the Definition of Done
- Engage the team: include the largest number of responsible team members during the planning stage; this will allow everyone to provide their point of view and bring topics to the table that otherwise would be seen later in the project. This improves the vision of the project and sets when one phase would end and another would begin.
- Create user stories: This valuable resource allows us to identify needs from the user’s point of view. The better defined they are, the easier it will be to determine when development is Done.
- Meeting all technical requirements: all functional and technical requirements must be met so that the development matches the accepted quality parameters, thus ensuring the expected performance of the application.
- Compliance with requirements: all the functionalities and requirements must be met at a technical level so that the development has the accepted quality parameters, thus ensuring the expected performance of the application.
- Functional and non-functional testing: validating the quality and properly testing all technical requirements 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.
Summary
The art of managing a project goes beyond dividing it into phases and allocating resources and delivery dates. The most important aspects are understanding the client’s requirements and having the technical expertise necessary to allocate resources correctly.
Huenei’s Agile Services Proposal includes agreeing with its clients on the Definition of Done, allowing transparency in the results and confidence in the work progress.
Likewise and as part of the commitment in the application of our Customer Orientation and Efficiency values, we monitor and carry out performance effectiveness metrics for our teams by measuring the level of rework due to deficiencies in the application of the Definition of Done and the acceptance criteria.
In terms of tasks, the entire team (both internal and on behalf of the client) must be in tune and understand what is needed for software development, feature, and functionality to be fully completed, allowing for the progress of the project, just like raising a flag to indicate that something is missing.