Definition of Done

A feature, user story, or task is considered "Done" only when all applicable criteria listed below are met and verified.

1. Core Quality & Completion

• All defined Acceptance Criteria for the story/task are fulfilled.
• To minimize major redesigns, the design handoff process must be strictly followed. This includes a formal walkthrough of the final Figma designs with the development team, where feasibility is confirmed, and any final questions are resolved before implementation begins.
• To ensure timely progress, all code changes must be reviewed and approved by the tech lead within A reasonable and flexible timeframe that would be:
  • Standard case: Review and merge should be done within 1 working day.
  • Complex or high-impact changes: May take up to 2 working days, with clear communication from the reviewer.
  • Exceptional cases: If a delay is expected, it must be commented on the task with a reason, as mentioned.
• No high-severity bugs are permitted at any stage of development or testing.
• Each feature must be verified by QA to ensure quality.
• If API documentation is required, this will be specified in the task's Acceptance Criteria and completed using an OpenAPI Specification (e.g., Swagger).
• Completed features result in a Demo-Ready Increment, which is validated during sprint reviews.
  • A feature is considered demo-ready when it is fully functional per its acceptance criteria, stable and integrated (Available on stage) suitable for demonstration.
• Only the Product Manager (PM) has the authority to move a task to the "Done" status after verifying that all other criteria have been met.

2. Technical Implementation Standards

Frontend

• The implemented UI accurately reflects the design team's specifications as defined in the Figma deliverables. This does not prevent collaboration; any design clarifications or adjustments discussed verbally must be documented in the comments of the relevant task.
• Provide error messages for form validation errors, with all copy provided by the design team and verified by a UX writer.
• Associate error messages with the relevant form fields.
• HTML files are minified (whitespace and comments removed).
• CSS files are minified.

JavaScript files are minified and uglified

• Images, scripts, and non-critical resources are lazy-loaded.
• Browser caching is implemented for static assets (e.g., using Cache-Control headers).
• Caching strategies are appropriate for different types of assets (e.g., long-term caching for static assets, short-term for dynamic).
• The number of HTTP requests is minimized (e.g., combining files, inlining critical CSS)
• Critical resources are preloaded to prioritize loading.
• The UI implementation effectively handles all expected validations, warnings, and exceptions, providing a smooth user experience.

Backend

API Design & Structure

• • API design adheres to RESTful principles (correct HTTP verbs, status codes). Example Provided in Examples tab.
    • Resources are identified and exposed via logical URLs, clearly named, and nested URLs. Limitations are enforced on API routes (allowed methods, request size limits, rate limiting).

Security & Validation

• • All user inputs are validated on the server-side(for user experience) and server-side (for security). The server-side validation is authoritative and must comprehensively check all inputs (data types, formats, lengths, constraints), as client-side validation can be bypassed.
    • Authorization controls are enforced to limit user access based on roles and permissions.

Error Handling & Stability

• • Proper exception handling is implemented to prevent crashes and exposure of sensitive information.
    • Standard and informative error codes (e.g., HTTP status codes) are returned to the client.

Database Management

• • Regular database backups are performed, and a recovery plan is in place. The dev team should provide a simple and standard verification way for the product and QA team.

3. Design Delivery & Change Management

Design Readiness & Handoff Responsibilities

At the time of Design Handoff, the following checklist must be fulfilled

• • Final Figma links accessible and up-to-date in Octuple
    • All screens and states ( empty, error, loading, …) covered
    • Interactions and behaviors clearly defined
    • Component specs match Design System
    • All criteria in the Design Readiness Checklist must be satisfied to meet the Definition of Ready (DoR)
    • ACs aligned with expected visual and behavioral design

The designer is responsible for verifying the completeness of the handoff in coordination with the Dev team

• Dev is responsible for raising a flag before starting development if:
  • Design is incomplete or unclear
  • Missing variants or interactions exist
  • Flow dependencies are undefined

⛔Development should not begin unless design is implementation-ready.

Accepting Design Changes During Development

• To maintain sprint focus and technical stability:

Developers can accept Minor Changes that

• • Require <1h work
    • Don't alter the acceptance criteria
    • Are aligned with DoD and current sprint goals
    • Are pre-approved by both designer & product Manager
• Major Changes must never be implemented directly. They must:
  • Be flagged in the task
  • Rejected or paused in current sprint
  • Be redirected to Product Backlog

⚠️Minor change ≠ low impact. If the change affects flow logic or test conditions, it's considered major even if it's small in UI.

Scope Change Policy for Design

• All design assets must be finalized and reviewed during Grooming and Planning before sprint start.

Minor design changes identified during development ( small UI alignment, wording updates, minor behavior tweaks) are acceptable only if they

• • Do not change the user flow
    • Do not introduce new logic or dependencies
    • Do not require major rework
• Major changes ( flow redesign, component swap, layout restructure, UX logic overhaul) must:
  • Be raised by the designer or dev team as a change request
  • Added to the Product Backlog as a new item
  • Reprioritized in a future sprint via Planning or Backlog Refinement

⛔No significant change in design scope should be handled silently within development. Clear traceability and team agreement is mandatory.

Scope Change & Change Management For Sprint

To preserve sprint integrity and team focus, all scope changes during the sprint must follow a structured change management policy. This prevents ambiguity, protects team commitments, and ensures accountability across roles

Minor scope changes — such as small UI tweaks, copy changes, or low-effort visual adjustments — may be accepted only if

• • They do not alter the story’s acceptance criteria
    • They do not impact the user flow or underlying logic
    • They require minimal effort (typically < 1 hour)
    • They are explicitly agreed upon by both the designer and the development team

Major scope changes — including flow redesigns, structural layout changes, new logic, or behavioral changes — must not be applied during the sprint. Instead

• • A new item must be created in the Product Backlog
    • The change must be groomed and reprioritized for a future sprint
    • The original story remains unchanged, preserving sprint commitment
    • They are explicitly agreed upon by both the designer and the development team

All scope changes must be documented clearly

• • Minor changes: updated directly in the task description or comments with approval noted
    • Major changes: tracked as a separate backlog item, linked to the original story if applicable

⚠️It is the responsibility of the Scrum Team to assess whether a proposed change qualifies as minor or major. Final arbitration may involve the Scrum Master and Product Manager if needed.

Timeliness:

• When a change is raised mid-sprint, team must decide within 12 working hours
• Scrum master facilitates sync decision via Daily Or Wave Group.

Changes implemented without visibility, agreement, or documentation will be flagged as process violations and subject to review in sprint retrospective.