Skip to main content

Project Definitions Guide

🚦 Definition of Ready (DoR)​

Before a task can be started, it must meet our DoR criteria. This ensures clarity and that all tasks started have been sufficiently prepared.

Criteria:​

  1. Description Clarity: Every task must have a clear and concise description, preferably using the Gherkin language.
  2. Prioritized Ticket: The importance and order of the task should be established.
  3. Jira Version Identified: The version or sprint in Jira should be set.
  4. Workshops: Before implementing, the developer should organize a workshop with the PM to ensure clarity. Document workshop decisions in JIRA comments.
  5. Subtasks: Ensure all development is related to a subtask, never directly to a US, TS, or Bug.
  6. Estimated: Only Subtasks should be estimated. They should be between 2-3 days. If more, reconsider its scope.
  7. Assigned Owner: There must be a designated responsible individual for the task.
  8. Acceptance Criteria: Acceptance Criteria must be defined
  9. Dependencies: Dependencies must be resolved

🏁 Definition of Done (DoD)​

Meeting the DoD ensures that our tasks maintain a consistent quality and that nothing is marked complete prematurely.

Criteria:​

  1. Unit Tests: All unit tests associated with the task should pass 100%.
  2. Code Review: The code should be reviewed by a peer or a team lead ( the MR must respect the Conventional Commit standard ).
  3. Code Merged: Completed code should be merged into the Staging branch. (If applicable)
  4. Proofs: Add a comment in each task (US, TS, Bug) describing the work done or providing proof of development.
  5. Delivery + CI: The delivery tested by QA must come from the CI.
  6. QA Test: Quality assurance testing should be completed and successful.
  7. Technical Documentation: If applicable, the technical documentation should be updated ( all documentation must be versioned in git ).
  8. Feedback Incorporation: All outputs/discussions from workshops should be incorporated and noted in subtask comments.
danger

Every commit should adhere to the Conventional Commit standard. This ensures clarity and a useful git history.