Definition of Done

A ticket is considered Done only when it has been fully implemented, reviewed, tested, accepted where applicable, and deployed to production.

Purpose

The Definition of Done ensures work is completed to an agreed quality standard, verified by the right people, and released to production before it is marked complete.

Ownership

• Developer: implementation and bug fixing
• QA: verification and validation on the branch or staging environment
• Tech Lead: engineering quality and code review oversight
• Product Owner: acceptance and product validation, where required
• Project Manager: release coordination
• Tech Lead / PO: deployment approval or coordination, depending on the release process

Accessibility Expectations

Accessibility ensures our web and mobile experiences work for everyone, regardless of ability or circumstance. It also helps us create products that are clearer, more resilient, and easier to use across different devices and contexts.

We use WCAG 2.1 Level AA as the baseline for Releaf products and design system components, with consideration given to newer WCAG guidance where feasible.

At a minimum, delivered work should follow the POUR principles:

• Perceivable: content includes text alternatives where needed, has sufficient contrast, and adapts to different screen sizes and zoom levels
• Operable: functionality works with a keyboard, focus is visible, and users can navigate without a mouse
• Understandable: content, labels, and interactions are clear, predictable, and supported by useful feedback
• Robust: experiences work reliably across browsers, devices, and assistive technologies

Checklist

A ticket can be moved to Done only when all of the following are true:

1. Development is complete

• The implementation matches the agreed ticket scope.
• No unfinished work is hidden behind “we’ll do it later”.
• Any follow-up work that is out of scope has been captured separately in a new ticket.

2. Code quality checks are complete

• Code review has been completed by the Tech Lead or assigned reviewer.
• No critical review comments remain unresolved.

3. Testing is complete

• QA verification has been completed.
• Requirements and expected results have been met.
• Bugs found during testing have been fixed.
• No open Critical or High severity defects remain.
• The change has passed a staging smoke test.
• If the release process differs outside sprints, the equivalent release-path checks have been completed.

4. Accessibility and compatibility checks are complete

• The change meets the relevant accessibility expectations for the feature or component.
• Interactive elements have an accessible name, visible focus, and keyboard support.
• Forms, validation, status messaging, and non-text content have been implemented accessibly where applicable.
• Colour is not used as the only means of conveying meaning.
• Motion is not required to understand the content, and prefers-reduced-motion is respected where relevant.
• The experience has been checked on a representative range of devices, screen sizes, and supported browsers.
• Responsive behaviour has been verified, including at 200% zoom on desktop and 320px width on mobile where applicable.
• Automated and manual accessibility checks have been completed where appropriate, including keyboard-only navigation and a screen reader spot check.

5. Product validation is complete, where required

• The ticket has been reviewed by the Product Owner where applicable.
• PO approval or confirmation has been received.

6. Release readiness is confirmed

• The ticket has been moved to Ready to Release after successful validation and staging smoke testing.
• Release notes have been added where applicable.

7. The change is live in production

• The ticket has been deployed to production.
• The deployment has been confirmed live.

Only at this point should the ticket be marked Done.