DEFINITION OF DONE TEMPLATE CODE
The source code has the proper Testing Coverage (according to expectations set, according to the Definition of Ready).
The source code has been integrated into the Continuous Integration, Delivery & Deployment pipelines and all builds /releases are passing.The code should have gone through a static code analysis (Sonar, TS Lint) and issues raised have been addressed.The issues raised by the reviewer have been addressed.The code has been reviewed by at least one senior team member.The code should have been peer reviewed using a git-based Pull Request with the below rules:.Code is checked in to the main branch and not on a repository branch or local machine.In order for the Product Owner to accept a user story as completed, the below items must be checked off: 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. All dependencies of the user story should be defined and marked as complete.The User Story needs to have team-validated Architecture & Design artifacts.The User Story needs to have team-validated User Interface & Experience artifacts.The value to the business should be straight forward and agreed upon with the product owner.The user stories should be weighed and assigned the proper story points.The non functional requirements should be defined and noted:.Reviewer has been identified and added in the acceptance criteria.Acceptance criteria has been fully defined.Feature has been agreed upon by relevant stake holders.The User story should be assigned to the parties responsible and these should be clearly defined and communicated to these parties.User story should be clearly defined, testable and feasible.Feature is in line with the functional requirements.With the above in mind, defined below is the Definition of Ready: The user story should be immediately actionable with no prior incomplete dependencies.The user story should be realistic and simple enough to be completed in one sprint.The user story should be in line with project priorities.The User Story must allow the team to identify the types of testing to be performed (unit testing, acceptance testing, security testing, etc). The User Story needs to enable effective means for the validation and acceptance of the functional and non functional requirements.The How: How is the feature going to look like (UI/UX)? How are we going to implement this (Architecture & Design)?.The What: What are we actually going to implement? What is the behavior of the system once the User Story has been completed?.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 Why: Why are we doing this? What is the expected business outcome?.In order for the Team to be able to accept a User Story into development, the given User Story needs to be: Hierarchy leaf 30 Service request process.Hierarchy leaf 20 Service Digitization Guideline.Hierarchy leaf 10 Architecture principles.Hierarchy leaf 04 Severity of Incidents.Hierarchy leaf 01 Standards for the "Definition of Done" (DoD).Hierarchy leaf 030 Default ToR for Government of Rwanda IT projects.
0 kommentar(er)
