Skip to main content

Definition of Ready and Definition of Done

The "Definition of Ready" (DoR) are the checks performed when a system epic, epic, feature, story, or bug is defined and ready to start work on. The "Definition of Done" (DoD) is the checks performed when the work items are completed before it is closed.

The Product Owner, Architect, and Scrum Master are responsible for system epics, epics, features, stories, and bugs – and the DoR/DoD helps them to assess the readiness and completeness.

note

General Rule

  • Never start working on something that is not Ready
  • Never stop working on something that is not Done

System epics, epics, features, and stories are secured by both acceptance criteria and DoD. Both need to be fulfilled before closing the work item.

The difference between the DoD and the acceptance criteria is that acceptance criteria are unique for an individual work item, resulting in test cases while the DoD is generic and the same checks are applied to each work item type including the acceptance criteria.

DoR and DoD for work items​

System-Epic​

Definition of Ready

  • Functional: The related system requirement is approved, including "Description", "Motivation", "Product line", "Compatibility", Verification criteria", "Priority", "Target release".
  • Functional: "Details" include a description of the solution intent.
  • Enabler/Architectural/UX/IP: Understandable title, description, and acceptance criteria
  • Area path set.
  • "Initial Effort Estimation" with "Confidence level" set.
  • Impacted development streams defined.
  • The system epic shall be ranked in the backlog for the target release.

Definition of Done

  • Confirm epics are completed.
  • System integration tests (SIT) have been passed.
  • Required documentation is reviewed and approved.
  • The result is demonstrated and accepted by PPM.

Epic​

Definition of Ready

  • Understandable "Title" and "Description".
  • Testable acceptance criteria established.
  • If/how to demo defined.
  • Effort estimated.
  • Link to system epic.
  • Dependencies to other epics defined.
  • Preliminary stream architecture defined (e.g. in PPT).
  • Draft features (including e.g. business, architecture, UX and documentation).
  • The area and iteration path are set.
  • Target date specified.
  • Security impact considered.
  • The epic is ranked in the backlog.
  • Epic reviewed.

Definition of Done

  • All child features are closed.
  • All product integration tests (PIT) passed, and existing bugs have CCB decision.
  • Product-level documentation approved (e.g. architecture and product capabilities).
  • Epic demonstrated.
  • Input to end-user documentation and release notes provided.
  • Installation/delivery package updated.

Feature​

Definition of Ready

  • Understandable "Title" and "Description".
  • Testable acceptance criteria established.
  • If/how to demo defined.
  • The feature is estimated to ensure it can be completed in an increment.
  • Preliminary design ready.
  • Draft user stories (including design and documentation).
  • Link to epic.
  • Dependencies on other features defined.
  • The area and iteration path is set.
  • Security impact considered.
  • The feature is ranked in the backlog.

Definition of Done

  • All child stories are closed.
  • All unit and component tests passed.
  • Component documentation approved (e.g. design and component capabilities).
  • Demo performed (or planned).

Story​

Definition of Ready

  • The story is clarified and accepted.
  • Enough information is provided to be able to start task breakdown by the teams.
  • The story is estimated to ensure it can be completed in a sprint.
  • Acceptance criteria are provided and agreed upon.
  • The story/enabler is aligned with the architecture.

Definition of Done

  • Confirm tasks are completed.
  • Impact on architecture, design, and interfaces identified and updated.
  • Code reviewed and issues fixed.
  • Static Code Analysis is performed, and issues are fixed.
  • Unit tests passed and included in the automated test environment.
  • Cumulative unit and functional regression tests passed.
  • End-user documentation is updated.
  • The story fulfills the acceptance criteria.

Bug​

Definition of Ready1)

  • Is sufficient information available to evaluate the bug (e.g., images, dumps, log files)?
  • Can the problem be reproduced?
  • Are severity, priority, and security effect assigned?

Definition of Done

  • Is the code reviewed and issues fixed?
  • Is the static code analysis performed and issues fixed?
  • Is the user documentation, including release notes, updated?
  • Is the architecture and design documentation updated?
  • For security-critical components and security-relevant bugs, are the threat models, attack surface and criticality analysis, and the security assessment updated?
  • Are the unit, functional, and/or security tests updated and passed?
  • Are other similar issues identified?
  • Are bugs created for other affected products or product versions?

1) The bug is "ready" when the investigation can start

How to work with DoD/DoR​

Adaption of DoD/DoR​

  • Based on the context and needs for a stream the DoR and DoD might need to be tailored.
  • Consider the context when adapting the DoR/DoD (HW, SW, FW, Embedded, HMI, DevOps, standards, etc.).
  • Ensure that the adapted version is documented and communicate the changes to all members and stakeholders.
  • Analyze results in retrospectives and refine the DoR/DoD as the streams and teams mature.
  • The "Head of Development" and "Head of Quality" approve the adaptations of the DoR/DoD – to make sure mandatory checks are included.

DoR/DoD when Appgami not integrated​

If the Appgami plug-in is not integrated into the collection, the DoR/DoD information needs to be added to the work item differently. There are some options:

  • add the DoR/DoD checklist to the "description" field
  • add it in the "validation" field (if present)
  • use the "discussion" field

For the "description"/"validation" fields, the DoR/DoD can be added to a template in ADO to reduce manual work.

DoR/DoD in Cloud Azure DevOps​

The DoR/DoD can be added to cloud Azure DevOps by Appgami for epics, features, stories and bugs in the information field.

  • The “ready” criteria can be added to the "Definition of Ready" area by choosing a proper template from Appgami.
    • The criteria could be customized inside the project team based on their product development.
    • The progress and status could be tracked by checking the criteria one by one.
  • The “done” criteria can also be the "Definition of Done" area by choosing a proper template from Appgami.
    • The criteria could be customized inside the project team based on their product development.
    • The sum of all “done” checks above progress corresponds to the recommended “Definition of Done”.
  • The teams check the boxes in the DoR/DoD information field before the epic/feature/story is moved to "Active" or 'Completed" in ADO.

If a DoR / DoD is "Not Applicable" it shall be agreed with relevant stakeholders (PO/RO/Dev Team) and marked as "SKIPPED" (see example below)

IMPORTANT: When "SKIPPED" is applied the criteria must be marked so that the DoD can be closed. (Reach 100%)

DoR:

image-2a.png

DoD:

image-2b.png

Discipline Dashboard in Azure DevOps​

Azure DevOps support setting up Dashboards to check the work items (e.g. for orphans, fields not filled in, etc.). The dashboards give an overview of a set of work items and can be combined with the Appgami checklists.

  • The Discipline Dashboards in Azure DevOps are indicators of some of the checks in a DoD/DoR.
  • Use the Discipline Dashboards to regularly monitor issues with the epics, features, and stories, and take action on deviations.

image.png

References​

Owner: Quality Processes Team