The Flexible Definition of Done

Software projects always take place in an organizational context, and their objectives are in line with organizational goals. Similarly, the sprints that build a project's road map need to have goals that are in line with those of the projects.

The interesting aspect of this is that goals and plans are not static in nature. They are iteratively and incrementally built, assessed and continuously prioritized in terms of the business value provided. Business value is dependent on time. Customer behavior changes with time, market opportunity windows appear (or disappear), and new markets can be entered at specific moments in time. As the product backlog is living and changing in time, in accordance with the new assessment of business value as discovered during latest market studies, the definition of done is a living object that has to be continuously adapted to the specific sprint and overall project goals.

Release Planning: The Basis for the Definition of Done

During release planning, project objectives are the central focus. Methods of measuring them are established in order to clarify how we know whether they're achieved or not. Some of these objectives are quantifiable and can be precisely conveyed into metrics, but others are more qualitative. For qualitative objectives, there are two ways to handle them: Translate them into quantifiable, measurable criteria or, in case a quantifiable measure is extremely difficult to express, address intersubjective understanding repeatedly, continuously assessing client feedback with regard to these objectives.

An example of such qualitative objectives would be the need for a GUI to be user friendly. This is difficult to quantify, but one could produce a quantitative measure such as the number of training days required for project stakeholders to be able to actually use the GUI, or the number of calls made to the project support team to address questions targeted to GUI usage.

As features change and the team, together with the stakeholders, learns more during the project, the GUI user-friendliness objective might take on different facets that weren't addressed initially. This way, an iterative intersubjective understanding can be acquired throughout client demos and sprint retrospectives in order to refine the understanding of an initially unquantifiable objective.

Sprint Objectives: Establishing the Definition of Done

The definition of done is the most important metric for assessing the completion of a product backlog item, and it must be understood in the same way by all team members. The sprint goals are the starting point in the refinement of the definition of done, and the sprint planning meeting should be seen as the opportunity to continuously update and refine the definition of done.

Iterative and incremental design are essential in Agile projects and represent the main technique for product development. Each sprint adds new business value and ensures that most important and risky aspects are handled first, providing for strong risk monitoring and better management of uncertainty. Thus, at each sprint planning meeting, the definition of done should be revised in accordance with sprint objectives. For example, it might be the case that crosscutting concerns such as performance and special security requirements are handled in the fourth and fifth sprints, respectively. Then sprint objectives such as "GUI responsiveness under peak load less than three seconds" should be included in the definition of done for the fourth sprint, and "System passes criteria for WebTrust compliance" in the fifth sprint.

Sprint review meetings and demos should be considered an important point in time when the definition of done is reassessed through the evaluation of actual sprint results, based on feedback and suggestions gathered from stakeholders. It's important that observations are tracked during these meetings and that these notes are used as the basis of further discussion and refinement withing the scrum team during the sprint planning meeting.

By continuously aligning the definition of done with each sprint's product and organizational objectives, we ensure its validity and viability within time, since the only constant in the world is change.

Conclusion

It's not unusual for project goals to be updated or changed; they depending on business value, which is affected by market conditions, which are changing continuously. Aligning the definition of done to the sprint, project, and organizational goals is key to ensuring the success of the project and an overall successful management of risk.