Definition of Ready

Purpose

In order for the Team to be able to accept a User Story into development, the given User Story needs to be:

• Clear
  • The Why: Why are we doing this? What is the expected business outcome?
  • The Who: Who will benefit from having this User Story completed? What are the User Roles, User Types or User Personas that will benefit from User Story?
  • The What: What are we actually going to implement? What is the behavior of the system once the User Story has been completed?
  • The How: How is the feature going to look like (UI/UX)? How are we going to implement this (Architecture & Design)?
• Testable
  • The User Story needs to enable effective means for the validation and acceptance of the functional and non functional requirements. The User Story must allow the team to identify the types of testing to be performed (unit testing, acceptance testing, security testing, etc).
• Feasible
  • The user story should be in line with project priorities
  • The user story should be realistic and simple enough to be completed in one sprint
  • The user story should be immediately actionable with no prior incomplete dependencies

Criteria

With the above in mind, defined below is the Definition of Ready:

• Feature is in line with the functional requirements
• User story should be clearly defined, testable and feasible
• The User story should be assigned to the parties responsible and these should be clearly defined and communicated to these parties.
• Feature has been agreed upon by relevant stake holders
• Acceptance criteria has been fully defined
• Reviewer has been identified and added in the acceptance criteria
• The non functional requirements should be defined and noted:
  • Reliability
  • Availability
  • Observability
  • Security
  • Deployment and performance
  • Maintainability
• The user stories should be weighed and assigned the proper story points
• The value to the business should be straight forward and agreed upon with the product owner
• The User Story needs to have team-validated User Interface & Experience artifacts
• The User Story needs to have team-validated Architecture & Design artifacts
• All dependencies of the user story should be defined and marked as complete.

Definition of Done

Purpose

The Definition Of Done establishes the acceptance criteria for the User Story deliverables, not just from the functional & non-functional compliance perspective but also from the perspective of the development process, artifacts and quality checks performed.

In order for the Product Owner to accept a user story as completed, the below items must be checked off:

• Code is checked in to the main branch and not on a repository branch or local machine
• The code should have been peer reviewed using a git-based Pull Request with the below rules:
  • The code has been reviewed by at least one senior team member
  • The issues raised by the reviewer have been addressed
• The code should have gone through a static code analysis (Sonar, TS Lint) and issues raised have been addressed
• The source code has been integrated into the Continuous Integration, Delivery & Deployment pipelines and all builds /releases are passing
• The source code has the proper Testing Coverage (according to expectations set, according to the Definition of Ready)
• All build, deployment and configuration changes are implemented, documented and communicated to the entire team
• Relevant diagrams or other types of documentation artifacts are updated in Open Project or Microsoft Teams
• All activities have been defined as sub-tasks and the time has been tracked/ logged in Open Project
• All subtasks are closed with the remaining time set to 0
• Feature has been ok'd by all relevant stakeholders.