Issue process and Definitions of Done (DoD)
Table of Content
- production cycle
- common rules
- product owner workflow
- graphical design workflow
- technical (dev) workflow
- At any step of a process, an issue can be put on hold or be returned to an earlier step.
- A Definition of Done (DoD) of a process step must be met and completed before an issue goes to any next step of the workflow.
Product Owner workflow
Review A member of the PO Team reviews the content of the opened issue and makes sure it meets the minimal and expected quality criteria. If some parts are not clear, the PO Team member contacts (e.g. through comments) the person who has opened the issue in order to clarify it. DoD: the issue is created and quality checked: A bug's type must be clear enough to identify and reproduce it. A feature's type must have a clear detail of the functional or non-functional requirements.
Implement For a bug: _skipped_ For a feature: a member of the PO Team defines and describes the functional specifications based on the requirements. For all types of issue, the PO Team sets a priority indication. DoD: the issue is quality checked, prioritised, and functional specifications for a feature are described.
Peer-review The PO Team reviews the issue and its priority indication. DoD: the issue meets the PO quality criteria and it is ready for Graphical Design (if relevant) or Dev Team review.
Quality Assurance skipped
Graphical Design workflow
Review The Graphical Design Team reviews the description of the issue and makes sure it is clear and understandable. If some parts are not clear, the Design Team contacts (e.g. through comments) the PO Team in order to clarify it. DoD: the issue is quality checked and ready for Graphical Design.
Implement The issue is being worked on by the Graphical Design Team. DoD: the graphical design is completed, and a merge request is submitted.
Peer-review The merge request and underlying code is reviewed by another member of the Graphical Design Team. DoD: the graphical design meets the graphical design principles and standards, the merge request is merged to the dev branch and deployed to the appropriate test environment (quality-assurance).
Quality Assurance The PO Team tests the implementation of the graphical design in the quality-assurance environment. DoD: the graphical design of the issue is validated and meets the user acceptance criteria.
Technical (Dev) workflow
Review The Dev Team reviews the issue and makes sure that the expected outcome of the fix/implementation/solution is clear, feasible and appropriate. If some parts are not clear, then the Technical Team contacts (e.g. through comments) the previous team in the process (PO Team, Graphical Design Team or .NET.SQL Dev Team). DoD: the issue is quality checked. It has been validated by both PO and Technical Teams and it is ready for Implementation.
Implement The issue is being implemented/solved by the Technical Team. Unit and feature tests are defined (when relevant) and performed (e.g. on a live API or based on mocks). DoD: the implementation is done, unit tests are green, and a merge request is submitted.
Peer-review The merge request and underlying code is reviewed by a Lead Developer who is responsible for the quality of the code base. DoD: development meets the coding standards, and the merge request is merged to the dev branch and deployed to the appropriate functional test environment (quality-assurance). The code is documented.
Quality Assurance The PO Team tests the implementation of the issue in the quality-assurance environment. DoD: the issue is fully tested and meets the user acceptance criteria. The feature is documented.