The Flexible Definition of Done

27 June 2012

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Dave Bales, CSC,CSP,CSM, 6/28/2012 2:02:46 AM
Have you encountered any teams working in this way, say for 20+ sprints or so?

I wonder what effects introducing variation into the definition of done will do to a team over the long term, i.e. introducing disturbances into the team's rhythms with respect to adjusting the team's understanding of their sprint forecast and correlated velocity.

Will a team be more adaptable and engaged and happy to question everything, or demoralised after chasing transient phantom dynamics in their retros?
Andreea TOMOIAGA, CSM, 6/28/2012 7:39:24 AM
Hi Dave, thank you for your comment. What I wanted to express was the adaptation of the definition of done during the course of a project since it is not static in nature, I did not mean a continuous readjustment for each and every sprint - this should occur when goals change during the course of the project. As points in time for adaptation retrospetives and review were proposed so the team is not disturbed during the sprints. For performance and compliance related concerns it might be the case that a group of sprints is needed in order to reach proposed goals. So yes, velocity can temporarily be negatively affected. In this case a continuous and iterative refinement of the goals would be useful. For example when the performance of the application has to be significantly increased, these performance goals should be incrementally and iteratively adapted throughout various sprints. This would avoid people becoming demoralized. I think this aspect is more likely to be encountered in the case of crosscutting/non functional requirements and not in the functional side of a project. What means "done" needs to be revised from one sprint to another, propagated and undersstood at team level, this was the main idea I wanted to convey here. If the requirements change too often then this is indeed a problem that in my opinion has to be solved elsewhere - and this way avoid the definition of done as a moving target on a regular basis.

You must Login or Signup to comment.