Undefined Done

Consequences: Pull is eliminated and throughput is reduced. Incremental releases cannot be made as it is not know what work is “done”. Metrics cannot be elicited, and it will be unclear if Sprint Goals are being met.

Applicability: 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 in a timely manner.

Structure: 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.

Motivation: Establishing a Definition of Done formalizes the means of by which 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.

Intent: Progress work as quickly as possible and without sufficient regard for quality

Proverbs: Nothing is done while something remains undone

Implementation: Scrum expressly requires a Definition of Done to be in place, although other agile methods may be less rigorous in this matter.