The Definition of DoneMuhammad Zeeshan Ali, PMP, PMI-ACP
When the work can be termed as “Done”?
The major issue in closing a project has been agreement on the point that the requirements have been completed and can be marked as done. It is not just the agreement between the Project Manager and the Customer but something that arises at every stage of the project among different stakeholders.
Everybody has its own definition and scope of done. For example for a developer his task will be done as soon as he/she has pushed the code to QA for testing. Same is the case for all other stages well but does that really satisfy the definition of done. The simple answer is that “No”, it doesn’t.
Many experts will argue that the definition of done is exactly the “Acceptable Criteria” stated in a User Story. It is a widely agreed point that the whole team works around that understanding.
My definition of “Done” is different. I think that the “Acceptance Criteria” is a sub part of “done”. For me “done” is when the customer agrees that it has been done. That means the story has satisfied all the “Acceptance Criteria” and then have been successfully deployed on Live Server and is working as per expectation of the client.
Some may disagree with my thought that this means that the customer may keep on changing things and work will never be done. I always respond that what a solution is worth if it is of no use or cannot satisfy the customer’s needs.
It is safe to suggest that the definition of “done” varies from project to project and person to person. Therefore it is always recommended for the team to agree among themselves and with customers on the definition of “done”. Acceptance Criteria will definitely drive the definition of “done” but also at what stage and status the customer should be notified of the task as done.
When teams are working in Agile methodologies, they are self-organizing and empowered. The team members can support each other and create effective and quality solutions only if they all know when it is “done”.