Definition of Ready

What is Definition of Ready (DoR)

The Definition of Ready is a set of agreements that lets everyone know when an item is ready to begin, e.g., when a user story is ready to be taken into a Iteration, and all necessary conditions are right for the team to start a Iteration. The DoR is not static, and we continuously work on it to include more stringent criteria and different aspects.

Characteristics of DoR

Clear, concise, auditable list of tasks that must be accomplished for a body of work to be considered READY (Potentially Shippable Product)
Created by the Team and modified as needed
It drives Quality, Accountability, Craftsmanship and removes ambiguity

Quick Links

Visibility of Work in the Value Stream Iteration Planning Onboarding a New Team Member Change Management

#	Items	DoR
1.	Epic (epics)	The Epic clearly and concisely outlines its purpose, business value, and desired outcomes. The Epic aligns with the overall strategic goals and objectives of the organization. Benefit hypothesis is complete - Epic's business value is identified and communicated, describing its potential benefits to the organization, customers, and stakeholders. Key measurement indicators/benefits (e.g., ROI, user experience, efficiency, etc.) are clearly defined An Epic Owner is assigned who takes ownership of Epic's success and is responsible for its prioritization and coordination. Key stakeholders are identified and engaged in providing input, feedback, and decision-making support throughout the Epic lifecycle. High-level requirements and epics are identified and documented, capturing the primary functionality and scope of the Epic. Any dependencies on other Epics, epics, systems, or external factors are identified and documented. UX and system/arch (including Azure) team has reviewed the requirements. Constraints, such as technological or regulatory limitations, are identified and considered during Epic planning and implementation. Required system design/architecture runway is completed and signed off. Epic's readiness for implementation is assessed, considering factors like technical feasibility, market readiness, and organizational readiness. Release planning is initiated, identifying the expected Minimal Viable Product (MVP) or increments that deliver value. Any 'fixed' 'Must-have' requirements are known - non-negotiable aspects of the epic are known, and their details are available. The backlog is sufficiently detailed and refined for effective Iteration planning and implementation. The Epic aligns with the objectives of the Agile Release Train (ART) and the current Program Increment (PI). All requirements (business rules and outcomes) and acceptance criteria are clearly defined. Epic T-shirt sizing is completed The Epic (epic) is testable and feasible. Clearly articulate if the epic is a cross-banner requirement
2.	Story	The User Story clearly and concisely describes what needs to be delivered and its purpose. The User Story follows the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable). The User Story has a priority assigned, indicating its relative importance compared to other stories. Any prerequisites and dependencies required for the successful completion of the User Story are identified and documented. The team estimated the User Story, providing a rough understanding of the effort and complexity involved. The User Story contains a refined estimate in Story Points. The User Story is testable and can be verified through appropriate testing techniques. High-level test scenarios that cover functional and non-functional aspects are defined. If the User Story requires bilingual support, bilingual testing scenarios are defined. Quality Engineers have reviewed the User Story for potential quality risks and testability challenges. The necessary test data is identified or available to perform the required testing for the User Story. The test environments needed for the User Story are identified, accessible, and properly configured. QE-specific automation scripts or frameworks are identified or developed to support efficient and effective testing. The User Story has clear UI expectations, including visual designs, layout guidelines, and specific UI interactions or animations. If the User Story involves a epic toggle, the toggle strategy and implementation details are documented and communicated. The User Story has well-defined acceptance criteria that outline the conditions for the story to be considered complete. Acceptance criteria with examples that are objectively testable/falsifiable are defined. Story acceptance criteria is defined in both English and French. In the case of BDD adoption, Gherkin scenarios are written in the Given-When-Then format to specify the expected behavior and outcomes. All UI designs are completed and attached to the story (If applicable). Tech design is completed and attached to the story (If applicable). API contract (swagger) is ready and attached to the story (if applicable). Sample test data has been identified and provided by the respective team or people (if applicable). Clearly articulate if the story is cross-banner and Toggle on/off behaviors are defined. Banner name should be added to AC. Stories are linked to epics/Enablers and traceable to the system requirements. NFR documentation required by the story is well defined and documented as acceptance criteria (If applicable) Security Performance Accessibility Analytic Automation Observability Data (data analytic & data lake) The team believes the story can be completed in a single Iteration (Along with other stories in the Iteration). PO & squad have identified which items from the acceptance criteria need to be included as part of pre-release regression testing for subsequent releases.
3.	Enabler	The Enabler has a clear and concise description that outlines its purpose, technical or architectural nature, and its contribution to the overall system or solution. The Enabler type is clearly defined (exploration, infra, architectural, and compliance). The Enabler's value, related to a business functionality or technical improvements, is identified and communicated. The value aligns with the strategic goals and objectives of the organization. An Enabler Owner is assigned, who takes ownership of the Enabler's success and is responsible for its prioritization and coordination. Key stakeholders, such as architects, technical leads, and other relevant team members, are identified and engaged in providing input, feedback, and decision-making support throughout the Enabler's lifecycle. The Enabler addresses technical debt, infrastructure needs, or any other non-functional requirements crucial for the system or solution's success. These requirements are identified and documented, capturing the necessary improvements or enhancements for the system's performance, scalability, security, or maintainability. Any dependencies on other Enablers, epics, systems, or external factors are identified and documented. Constraints, such as technical limitations, compliance requirements, or integration considerations, are identified and considered during the Enabler's planning and implementation. The Enabler's readiness for implementation is assessed, considering factors like technical feasibility, impact analysis, and potential risks. The assessment helps determine if the Enabler is ready to be prioritized and included in the implementation plan. The Enabler backlog is created, capturing the prioritized list of tasks, activities, or technical deliverables required for the Enabler's implementation. The backlog is sufficiently detailed and refined to enable effective planning, implementation, and validation. The Enabler aligns with the Agile Release Train (ART) objectives and the current Program Increment (PI). The Enabler's prioritization and sequencing are in sync with the overall priorities and plans of the organization. The Enabler must fit in Iterations/iterations like any Story

#

Items

DoR

1.

Epic (epics)

The Epic clearly and concisely outlines its purpose, business value, and desired outcomes.
The Epic aligns with the overall strategic goals and objectives of the organization.
Benefit hypothesis is complete - Epic's business value is identified and communicated, describing its potential benefits to the organization, customers, and stakeholders. Key measurement indicators/benefits (e.g., ROI, user experience, efficiency, etc.) are clearly defined
An Epic Owner is assigned who takes ownership of Epic's success and is responsible for its prioritization and coordination.
Key stakeholders are identified and engaged in providing input, feedback, and decision-making support throughout the Epic lifecycle.
High-level requirements and epics are identified and documented, capturing the primary functionality and scope of the Epic.
Any dependencies on other Epics, epics, systems, or external factors are identified and documented. UX and system/arch (including Azure) team has reviewed the requirements.
Constraints, such as technological or regulatory limitations, are identified and considered during Epic planning and implementation. Required system design/architecture runway is completed and signed off.
Epic's readiness for implementation is assessed, considering factors like technical feasibility, market readiness, and organizational readiness.
Release planning is initiated, identifying the expected Minimal Viable Product (MVP) or increments that deliver value. Any 'fixed' 'Must-have' requirements are known - non-negotiable aspects of the epic are known, and their details are available.
The backlog is sufficiently detailed and refined for effective Iteration planning and implementation.
The Epic aligns with the objectives of the Agile Release Train (ART) and the current Program Increment (PI).
All requirements (business rules and outcomes) and acceptance criteria are clearly defined.
Epic T-shirt sizing is completed
The Epic (epic) is testable and feasible.
Clearly articulate if the epic is a cross-banner requirement

2.

Story

The User Story clearly and concisely describes what needs to be delivered and its purpose.
The User Story follows the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable).
The User Story has a priority assigned, indicating its relative importance compared to other stories.
Any prerequisites and dependencies required for the successful completion of the User Story are identified and documented.
The team estimated the User Story, providing a rough understanding of the effort and complexity involved. The User Story contains a refined estimate in Story Points.
The User Story is testable and can be verified through appropriate testing techniques.
High-level test scenarios that cover functional and non-functional aspects are defined.
If the User Story requires bilingual support, bilingual testing scenarios are defined.
Quality Engineers have reviewed the User Story for potential quality risks and testability challenges.
The necessary test data is identified or available to perform the required testing for the User Story.
The test environments needed for the User Story are identified, accessible, and properly configured.
QE-specific automation scripts or frameworks are identified or developed to support efficient and effective testing.
The User Story has clear UI expectations, including visual designs, layout guidelines, and specific UI interactions or animations.
If the User Story involves a epic toggle, the toggle strategy and implementation details are documented and communicated.
The User Story has well-defined acceptance criteria that outline the conditions for the story to be considered complete. Acceptance criteria with examples that are objectively testable/falsifiable are defined.
Story acceptance criteria is defined in both English and French.
In the case of BDD adoption, Gherkin scenarios are written in the Given-When-Then format to specify the expected behavior and outcomes.
All UI designs are completed and attached to the story (If applicable).
Tech design is completed and attached to the story (If applicable).
API contract (swagger) is ready and attached to the story (if applicable).
Sample test data has been identified and provided by the respective team or people (if applicable).
Clearly articulate if the story is cross-banner and Toggle on/off behaviors are defined. Banner name should be added to AC.
Stories are linked to epics/Enablers and traceable to the system requirements.
NFR documentation required by the story is well defined and documented as acceptance criteria (If applicable)
- Security
- Performance
- Accessibility
- Analytic
- Automation
- Observability
- Data (data analytic & data lake)

The team believes the story can be completed in a single Iteration (Along with other stories in the Iteration).
PO & squad have identified which items from the acceptance criteria need to be included as part of pre-release regression testing for subsequent releases.

3.

Enabler

The Enabler has a clear and concise description that outlines its purpose, technical or architectural nature, and its contribution to the overall system or solution.
The Enabler type is clearly defined (exploration, infra, architectural, and compliance).
The Enabler's value, related to a business functionality or technical improvements, is identified and communicated.
The value aligns with the strategic goals and objectives of the organization.
An Enabler Owner is assigned, who takes ownership of the Enabler's success and is responsible for its prioritization and coordination.
Key stakeholders, such as architects, technical leads, and other relevant team members, are identified and engaged in providing input, feedback, and decision-making support throughout the Enabler's lifecycle.
The Enabler addresses technical debt, infrastructure needs, or any other non-functional requirements crucial for the system or solution's success.
These requirements are identified and documented, capturing the necessary improvements or enhancements for the system's performance, scalability, security, or maintainability.
Any dependencies on other Enablers, epics, systems, or external factors are identified and documented.
Constraints, such as technical limitations, compliance requirements, or integration considerations, are identified and considered during the Enabler's planning and implementation.
The Enabler's readiness for implementation is assessed, considering factors like technical feasibility, impact analysis, and potential risks.
The assessment helps determine if the Enabler is ready to be prioritized and included in the implementation plan.
The Enabler backlog is created, capturing the prioritized list of tasks, activities, or technical deliverables required for the Enabler's implementation.
The backlog is sufficiently detailed and refined to enable effective planning, implementation, and validation.
The Enabler aligns with the Agile Release Train (ART) objectives and the current Program Increment (PI).
The Enabler's prioritization and sequencing are in sync with the overall priorities and plans of the organization.
The Enabler must fit in Iterations/iterations like any Story