Key Principle: Maintain a Releasable Level of Quality

The Definition of Done applies to individual items. Beyond that, ensuring that the overall code base is kept at a releasable level of quality at all times provides a quality safety net that supports efficiency in many other practices, including coding, debugging, and obtaining meaningful user feedback.

The discipline of frequently driving software to a releasable level of quality provides two important benefits.

The first benefit is that maintaining a releasable level of quality minimizes the gap between defect insertion and detection. If you bring the software to a releasable level of quality every 1–3 weeks, you will never allow that gap to open very wide. This assures a high level of quality. The more often the software is driven to a high level of quality, the easier it is to maintain it at that level and avoid accumulating technical debt.

The second benefit is support for project planning and tracking. If software is driven to a releasable level of quality by the end of each sprint, that implies that there is no more work to do on that functionality later. If software is not driven to a releasable level of quality, that means an undetermined amount of additional quality-improvement work must be done later. Quality improvement work accumulates across sprints, which undermines the ability to determine the true status of the project.

For both these reasons, it is important for teams to drive their work to a releasable level of quality by the end of each and every sprint. In many cases, you will put that work into production when it is completed. In some cases, this may not be appropriate—for example, if you work in a regulated environment, your software releases are tied to hardware releases, or the work has not yet crossed the minimal viable product threshold.

Reduce rework

“Rework” refers to work on items that had previously been declared to be “done.” It includes bug fixes, misunderstood requirements, modifications of test cases, and other corrections to work that should have been done correctly in the first place.

Rework is disruptive to projects because the amount of rework is unpredictable, projects don’t allow time for it in their plans, and it creates no additional value.

Measuring rework as a means of reducing it is useful, and this topic is discussed more in the “More Effective Agile Measurement” chapter.