Firefox/HowTo-DOD

What It Is

• Team needs to discuss and agree upon a definition of done that defines a potentially shippable product increment.
• Each individual work item brought into an iteration will then be expected to comply with these criteria before being considered complete.
• The elements that comprise a team’s definition of done are like the conditions of satisfaction/acceptance criteria that are applied to a feature in the product backlog - but at a macro level.
• A potentially shippable product increment means compliance with the individual conditions of satisfaction/acceptance criteria of the feature and the global definition of done.

Example #1

The project employs a Definition of Done to confirm when Work (Features, Defects and Changes) is complete. This will ensure the project does not carry forward any technical debt.

A feature, defect or change can exist in one of three states:

1. Not Started - exists in a Backlog for development in a future iteration.

2. Incomplete - development finished in a previous iteration but contains dependent defects and/or change requests.

3. Complete - development finished in a previous iteration and contains no dependent defects and/or change requests.

The following criteria will apply to a feature, defect or change to consider them complete:

• task complete - all individual work dependencies are closed.
• quality complete - reviewed by QA, passed testing requirements and has no open defects and/or change dependencies.
• product complete - reviewed and accepted by Product Manager and has no open defects and/or change dependencies.

Any feature, defect or change that conforms to the DOD is included as part of the Release Build.

Example #2

The project employs a Definition of Done to ensure a potentially shippable product is released at the conclusion of the iteration.

Potentially Shippable Guidelines:

• Means Tested
• Does Not Mean Cohesive

The following criteria will apply to a feature, work, defect or change to consider them complete:

• code complete - development satisfies the acceptance criteria of the feature/change or corrects the defect.
• quality complete - reviewed by QA and passed testing requirements.
• product complete - reviewed and accepted by Product Manager.

Any feature, work, defect or change that conforms to the DOD is included as part of the Iteration Build.

Notes

• Need to discuss the practical implications of what the DOD means. For ex, if a bug is code complete and has landed at the end of an iteration but has not passed QA does it stay on the train for QA to verify after it has been corrected or is it backed out and then corrected? Does the response to this question change if the sprint happens to coincide with an uplift to Aurora?
• Note: Any reliance upon QA is dependent upon QA agreeing to work in one of these ways.