Everyone loves the feeling of relief and satisfaction after finishing a big project and delivering a complete, high-quality work product. Unfortunately, the path to getting there is often littered with delayed or incomplete deliverables, resulting in dissatisfaction between both team members and project sponsors.
For Agile projects, incomplete tasks can cause a range of problems including slowing velocity, undermining quality, and constant churn around what is supposed to be being delivered. To avoid this, it's essential that the team and project sponsors agree on both what is going to be delivered, and how it is judged to be complete - the "definition of done", or DoD.
When beginning an Agile project, it is vital to know from the beginning what you want your end results to look like. The establishment of goals, a project scope, and a thorough understanding of customer needs are all activities that should occur before a project is started.
The Agile project team then translates the goals and needs into a specific set of deliverables that define exactly when a project may be considered complete. Each deliverable will have a "definition of done" which describes what is required to be regarded as complete and count towards the velocity of a project.
Unfortunately, along with several other Agile terms, the DoD often gets lost in translation… and creating and agreeing on a comprehensive description of "done" itself remains incomplete.
So, what could a generic “definition of done” for sprints, increments, and releases actually look like at each level of enterprise delivery? What should it contain that would deliver value to an end user while providing sufficient guidelines and support for a development team?
On the business level, there are a lot of criteria that need to be fulfilled until an envisioned project may be placed in a backlog for development. Such criteria includes wireframes, screen mockups, requirements, high level test criteria, and fully developed epics. These epics must be agreed upon by the Product Owner, Program Manager, and Scrum Master.
A sprint may be considered done only when the Product Owner (or PO) accepts the deliverable (an Epic, Story, or Function) that was completed during the sprint. The acceptance will occur if the PO has been satisfied after the team's sprint demonstration (or Sprint Demo) during the Agile Development Process.
The Epic, Story, or Function created in the sprint will be considered done once it has been successfully integrated into a program or system and has been accepted by the designated User or Representative. This User will then place the Epic/Story/Function into the project's release backlog.
The next phase is the deployment of the completed Epic, Story, or Function into its production environment. Once all documentation for the project has been submitted and accepted, an Agile project may finally be considered 'done.'
Trying to release an unfinished Agile project may have detrimental effects. It could leave your team members confused, your requirements unfulfilled, and your customers' needs unmet.
Ultimately, prematurely labeling your project as 'done' will cost more time, energy, and resources than planning ahead and thoroughly defining requirements before the project is started. Although this process requires more work up front, having a definition of done will help to maintain the simplicity and efficiency throughout your Agile project.