Antipattern of the Month: Undefined Done
Find out more!
Join the DZone community and get the full member experience.Join For Free
Agile teams are self-organizing and cross-functional. Between them, team members must demonstrate all of the skills and capabilities that are needed to deliver usable increments of a product or service, early and often. In Scrum, for example, all of the design, implementation, testing, and integration work must be performed in no more than one calendar month.
You may also like: Eleven Continuous Delivery Anti-Patterns
That’s the maximum length of a “Sprint” for delivering a valuable product increment. The standard that is required for each increment to be of release quality is enumerated in the Scrum Team’s Definition of Done.
In practice, supposedly “agile” teams are very often short-changed on this matter, and it is surprisingly rare for one to have all of the competencies needed to create “Done” increments of work. These teams may not, in truth, be able to meet a Definition of Done which is of release quality. The reasons for this are varied. In some cases, the team may not have a continuous integration and deployment capability to facilitate the timely elevation of work into production.
They might be also inhibited by organizational problems, such as dependencies upon people who lie outside of the team. They may be dependent upon architectural, security, or database specialists, for example, or they might require authorization from a Change Control Board to be able to release work into production at all.
A so-called “agile” team can very often only take work so far, and technical debt of one sort or another will have to be remediated before any increment they produce is genuine of release quality. This means that there will be a failure to establish empirical process control, because the release is deferred, and the team’s ability to inspect and adapt its progress based on evidence will be impeded.
If this is the case then the problem ought to be made clear, such as by enumerating the deficit for release. This would indicate that agile delivery is not in effect.
By reducing transparency over what Done means, problems such as these are effectively hidden, and the need to deal with them is deferred until some indeterminate future point. A common motivation for obscuring the Definition of Done is fear or suspicion of transparency.
For example, certain stakeholders may perceive an advantage if “Done” is poorly understood or applied, because this weakness might allow them to extend scope further. Novice team members can also object to having their technical standards opened to scrutiny.
Example Definition of Done
Remember that a Definition of Done properly applies to an increment.
1. Environments Are Prepared for Release
First, check that no unintegrated work in progress has been left in any development or staging environment. Next, check that the continuous integration framework is verified and working, including regression tests and automated code reviews.
The build engine ought to be configured to schedule a build on check-in. It may also trigger hourly or nightly builds. Also, check that all of the test data used to validate the features in the release has itself been validated.
2. Handover to Support Is Complete
(Note: This may be elided in a DevOps context or where the Dev Team will follow the product through to support)
All design models and specifications, including user stories and tests, must be accepted by support personnel who will maintain the increment henceforth. Note that they must also be satisfied that they are incompetent control of the supporting environment.
3. Review Ready
Part of the work in a Sprint includes preparing for the review. Sprint metrics ought to be available, including burn-down or burn-up charts. Any user stories which have not been completed ought to be re-estimated and returned to the Product Backlog.
4. Code Complete
- Any “To Do” annotations must have been resolved, and the source code has been commented on to the satisfaction of the Development Team. Source code should have been refactored to make it understandable, maintainable and better able to support future change.
- Note that the Red-Green-Refactor pattern found in Test Driven Development is helpful here.
- Unit test cases must have been designed for all of the features in development, and allow requirements to be traced to the code implementation such as by clear feature-relevant naming conventions. The degree of Code coverage should be known and should meet or exceed the standard required. The unit test cases should have been executed and the increment proven to work as expected.
- Peer reviews ought to be done. (Note: If pair programming is used, a separate peer review session might not be required). Source code is checked into the configuration management system with appropriate, peer-reviewed comments added. The source code should have been merged with the main branch and the automatic deployment into elevated environments should be verified.
5. Test Complete
Functional testing should be done. This includes both automated testing and manual exploratory testing, and a test report should have been generated. All outstanding defects (or incidents such as build issues) should be elicited and resolved, or accepted by the team as not being contra-indicative to release. Regression testing has been completed, and the functionality provided in previous iterations has been shown to still work.
Deficit for Release
"Done" criteria that are needed to effect a release, but which cannot yet be achieved by the team, constitute a deficit. They should be enumerated here (e.g. by moving them out of the Definition of Done). A deficit implies that Scrum is not yet being implemented and that there is likely to be technical debt.
6. Performance, Security, and User Acceptance Testing Must Have Been Done, and the Product Should Be Shown to Work on All Required Platforms.
7. Release Authorization Must Be Obtained.
Progress work as quickly as possible and without sufficient regard for quality.
Nothing is done while something remains undone.
Establishing a Definition of Done formalizes how work is accepted. Customers may have little incentive to formally accept work as being complete, as to do would give them no advantage while also reducing their opportunity to demand rework, or to extend the original scope under the guise of rework. Some development team members may, for their part, object to the improved transparency that a Definition of Done brings to their working practices.
Team members iterate over an ordered backlog of items; however, there is no clear separation between work that is in progress and that which is complete. Multiple items are actioned simultaneously and WIP is not limited. Customers may be partially in receipt of some work that is in progress.
Authoring a Definition of Done is particularly hard when the type of work varies, such as in technical support. However, a specification of “done” is still possible if it is expressed in terms of review and signoff. Customers may face penalties or restrictions if they fail to approve work promptly.
The pull is eliminated and throughput is reduced. Incremental releases cannot be made as it is not known what work is “done”. Metrics cannot be elicited, and it will be unclear if Sprint Goals are being met.
Scrum expressly requires a Definition of Done to be in place, although other agile methods may be less rigorous in this matter.
Opinions expressed by DZone contributors are their own.