We know what is necessary to plan, estimate, execute, and control the risks, processes, and other factors to get the agile project work completed.
One important question must be answered: “What does complete look like?” Or “What is considered done and what is considered DONE?” Yeah, that last one sounded like I just repeated the question, but stuttered the second time. Nevertheless, there is a fundamental difference between those two almost identical questions. If those two questions are not answered, there is no way we can close a user story, an iteration, or an entire project.
The definition of done is important in any project, but doubly important in agile projects because of the open and flexible adaptive planning that occurs. The shifts and the changes may skew the original designations of what was viewed as “done.” As we adapt in our planning, testing, and managing of the work, we must also adapt in our agreement of what is “done.” Staying in constant contact and partnership with customers, business representatives, and the product owner, we include in those conversations what done looks and feels like. Setting and managing those expectations promotes the likelihood of meeting those expectations and reducing the risk of not completing work or being able to reach success because the definition of done was not clear or agreed to. If stakeholders are working closely throughout the project and have a shared understanding of what is done, then that eases the tensions around disagreements later.