Skip to navigation
Quality Engineering

Definition of Done-(DoD)

A Product Backlog Item is Done only when all items below are satisfied with no exceptions.

1. Functional Completeness

  • All Acceptance Criteria defined in the PBI are fully implemented.

  • Business logic behaves exactly as described, including edge cases and error scenarios.

  • The change integrates correctly with dependent microservices (APIs, events, contracts).

  • No partially implemented functionality, feature toggles left unmanaged, or TODOs remain.

  • The PBI delivers the intended business value and does not rely on future work to function.

2. Code Quality & Engineering Standards

  • Code follows agreed coding standards, architectural guidelines, and microservice conventions.

  • No critical or high‑severity static analysis, lint, or quality gate violations remain.

  • Code is readable, maintainable, and appropriately modular.

  • Configuration is externalized (no hard‑coded environment values or secrets).

  • Service contracts (API schemas, events, DTOs) are versioned and backward‑compatible where required.

3. Testing Requirements

3.1 Unit Testing

  • Unit tests are written for new or modified logic.

  • Unit tests cover positive paths, negative paths, and edge cases.

  • All unit tests pass in the CI pipeline.

  • Minimum agreed code coverage threshold is met.

3.2 Integration Testing

  • Integration tests validate service‑to‑service communication.

  • API endpoints, message queues, or event streams are tested end‑to‑end.

  • All integration tests pass in CI/CD.

3.3 Regression Testing

  • Existing automated regression tests pass without failures.

  • The change does not introduce regressions in related functionality.

  • Manual regression testing is executed when automation is not feasible, and results are documented.

4. Acceptance Criteria Validation

  • Acceptance Criteria are explicitly validated through tests or demonstrations.

  • Evidence (test results, screenshots, logs, or recordings) is attached to the PBI where applicable.

  • The behavior matches intent, not just literal wording.

  • The Product Owner (or designated proxy) has reviewed and accepts the PBI.

5. Documentation Updates

  • Technical documentation is updated (README, service docs, ADRs, API specs).

  • API changes are reflected in OpenAPI/Swagger or equivalent contracts.

  • Configuration, deployment, or operational changes are documented.

  • Code is meaningfully commented where logic is non‑obvious.

  • Any new feature flags, environment variables, or toggles are documented.

6. Security & Compliance

  • No secrets, credentials, or tokens are committed to source control.

  • Security scans (SAST, dependency, container, or image scans) pass.

  • Authentication and authorization rules are correctly enforced.

  • Input validation and error handling prevent common vulnerabilities.

  • Compliance requirements (audit logging, data privacy, retention) are met where applicable.

7. Performance & Reliability

  • No significant performance degradation is introduced.

  • Resource usage (CPU, memory, connections) is within acceptable limits.

  • Timeouts, retries, and circuit breakers are configured appropriately.

  • Logging, metrics, and tracing are in place for new or changed functionality.

  • The service behaves correctly under expected load patterns.

8. Peer Review & Collaboration

  • Code has been peer‑reviewed by at least one qualified team member.

  • All review comments are addressed or explicitly resolved.

  • No self‑approved pull requests.

  • The change aligns with shared team and architectural standards.

9. Deployment & Release Readiness

  • Code is merged into the agreed target branch.

  • CI/CD pipelines complete successfully without manual intervention.

  • The PBI could be released to production at the end of the sprint.

  • Feature toggles are correctly configured for release strategy.

  • Rollback or mitigation strategy is understood if the change fails.

10. Environment & Configuration Changes

  • Required environment variables, secrets, or configuration values are defined.

  • Infrastructure‑as‑Code changes (if any) are applied and validated.

  • Changes are deployed and verified in the appropriate environment(s).

  • No manual, undocumented environment steps are required.

  • All environments remain in a deployable, consistent state.

Final Confirmation

  • No critical or high‑priority defects remain open.

  • The team agrees the PBI meets the Definition of Done without exceptions.

  • The increment is potentially shippable.