The Definition of Ready is applied to make sure that the team has enough information about a product backlog item (PBI) to be able to implement it in an upcoming sprint. The team defines what needs to be included in a PBI to ensure that it is:

• Of value to the customer,
• Clearly articulated and understood,
• Actionable, so that the team knows what needs to be done (and how),
• Achievable within the iteration (i.e., sized appropriately), and
• Testable.

The outcome is a list of criteria, agreed upon by the team, and prominently displayed. All the criteria must be met, and the backlog item must be estimated before it is considered ready for development.

Criteria included as part of Definition of Ready:

• There is sufficient detail and clarity to start development work, e.g.,
  • Supporting domain knowledge,
  • Any business context on how the user story part is part of a larger narrative,
  • Business rules added,
  • User interface mock-ups required for visual clarity,
  • Non-functional requirements specified, and
  • Data elements defined and data modelling/mapping completed.
• The PBI meets the "INVEST" criteria:
  • Independent of other user stories (as much as possible),
  • Negotiable for changes,
  • Valuable to the customer, stakeholder, or team (based on preferred value metric),
  • Estimable to help rank and schedule its implementation,
  • Small enough to be completed in an iteration, and
  • Testable (even if tests are yet to be created).
• It is sized using relative estimation.
• Acceptance criteria are clearly defined.
• Resources are available and assigned to work on the story.
• The team knows how to demonstrate the completed backlog item.

Definition of Ready can be applied to items other than PBIs. For example, a release plan can have the Definition of Ready criteria before new features are rolled out to the customers. Definition of Ready may include:

• High-level capacity plan for delivery and support resources.
• Size estimates for the PBIs that include:
  • PBI elaboration,
  • Development, and
  • Testing efforts.
• High-level dependencies, including
  • Technical,
  • Operational, and
  • Business considerations.
• Release criteria, including:
  • Any hardening, or stabilization requirements.

The Definition of Delivery requires the team to collaboratively define what needs to be done to be ready for delivery. It is especially useful in complex product releases. The value is in the transparency it creates for business stakeholders and the confirmation that all activities needed for successful delivery are identified and aligned. The Definition of Delivery includes what needs to be done and who needs to do it.

The items identified as Definition of Delivery may be added as PBIs to the product backlog. This approach facilitates recording additional information like tasks, task assignments, due date, and time to completion to Definition of Delivery criteria. It demonstrates that all the readiness activities have been met for delivery.

The Definition of Delivery:

• Becomes part of the product roadmap and release plan, contributing to a shared understanding of work to be done.
• Provides visibility and transparency of the progression for the readiness of product delivery.
• Adds a level of granularity to the product roadmap, which brings meaning and clarity.
• Reinforces the value of, and keeps the focus on, setting goals and measuring progress.
• Identifies marketing, training, technical support, and the detailed product rollout plan, or any other activities identified through input from the team and stakeholders.
• Is influenced by the Agile Framework employed by the team.

Readiness items that may be included in the Definition of Delivery:

• Marketing
  • Branding
  • Materials
  • Delivery
  • Videos
• Training
  • Manual
  • Quick Reference Guide
  • FAQ
  • Videos
• Quality
  • Open or known defects resolved
• Technical
  • Security
  • Operational deployment plan
• Production support
  • 1st level
  • Escalations

The Definition of Done is used to clarify understanding of what completeness means for PBI work, iteration work, and feature work. It helps to ensure that there is a unified understanding and agreement on quality standards. It consists of a list of criteria that must be met before a work item is considered done. Like all definition concepts in Agile, Definition of Done is a collaborative team effort that must be prominently displayed for the team.

This concept helps support the Definition of Delivery and provides the opportunity to collaborate and communicate across the delivery team and stakeholders. It sets expectations and helps to navigate the confusion that sometimes exists among the delivery team and stakeholders concerning when a PBI is considered complete. Teams that operate based on clearly articulated Definition of Ready, followed by Definition of Done, accelerate velocity, delivery, and ease of acceptance of PBIs.

Examples of criteria under a PBI's Definition of Done include:

• Development has been unit tested.
• 80% of the code has been reviewed.
• Code meets style guide and enterprise architecture standards.
• 100% of acceptance criteria have been developed and passed testing.
• Public API documented according to standards.
• Product note has been updated.
• PBI has been approved by most stakeholders in the product review team.

Definition Criteria

All the definition concepts include a mutually agreed upon set of independently verifiable criteria. The criteria are statements of common understanding within the team for PBIs intended for a specific goal (development, release, completion etc.). It is a good practice to stay agile and not over-specify the definition criteria. The product team agrees upon the level of detail required for the definition criteria.

Mode of Communication

All the definition concepts promote shared understanding. Therefore, the mode of sharing must be selected carefully. All criteria should be always available to the team.

.1 Process to Create Definition Concepts

• Begin with a collaborative session (e.g., an iteration, release, or delivery planning session):
  
  • All the criteria for the definition concepts require a shared understanding and trust between team members, and
  • Goals for the definition concepts need to be defined and the differences explained to the team.
• Create a checklist to verify the definitions:
  
  • For Definition of Done (DoD), a checklist may contain a set of criteria that outline the team's understanding of "Done."
  • The Definition of Ready may include a checklist of expectations from the team that outline whether they feel comfortable with the
    selected PBIs.
  • The definitions may span multiple PBIs, unlike the acceptance criteria, which are tied to a specific PBI, Epic, or story.
• Review the definitions:
  
  • The quality attributes of PBIs are usually similar so they can be applied across many PBIs. However, the definitions may require
    timely revisions as:
    
    • The understanding of team members matures,
    • Introduction of new team members, or
    • The product undergoes directional changes.

Strengths	Limitations
It is visible and accessible to all team members, so there is a limited number of assumptions. It significantly reduces the risk of building something incorrectly. It is an effective communication tool and orients team members to a shared focus. It can be easily modified to include organizational considerations.	It can be confused with acceptance criteria. It requires team members to have a shared understanding of the criteria. When the team changes, the criteria may require updates. It minimizes the risk of unintended features to be delivered but does not ensure customer acceptance.

Tips for Success

• Be clear and specific with definition criteria. For example, there is a difference between:
  
  • “Acceptance criteria must be met." vs. "100% of acceptance criteria have been developed and passed testing." The latter criterion is specific in what it means for acceptance criteria to be met.
• Ensure the criteria is achievable. For example, include a criterion such as:
  
  • “Product shipped to the customer" is not feasible for every work increment, or
  • "The customer will save X amount of time per transaction" criterion cannot be met prior to Done.
• The criteria must be agreed upon by the whole team since it is a commitment to quality work.
• The criteria should be revisited and revised if issues arise after PBIs are accepted by the team during product delivery. Retrospectives provide a good opportunity for a review of definitions.