Skip to main content

Ready and done

Clear quality gates let teams move quickly without transferring uncertainty or avoidable risk to someone else.

Definition of Ready​

Before implementation begins:

  • the user, problem, intended outcome, and acceptance criteria are understood;
  • the primary success measure and important guardrails are defined;
  • relevant design or technical review has occurred;
  • required assets and dependencies are available or explicitly planned;
  • important edge cases, constraints, and requirement owners are visible;
  • the delivery risk tier and required evidence are agreed; and
  • the contributing disciplines agree on scope and ownership.

Delivery risk tiers​

Use the lightest process that can responsibly protect the people and systems affected:

  • Contained and reversible: peer review, a defined measure, and an easy rollback or reset.
  • Customer-visible but reversible: QA, staged release, monitoring, and an explicit rollback path.
  • High-impact or difficult to reverse: qualified independent review, stronger evidence, explicit go/no-go authority, and a rehearsed recovery plan.

Security, financial, legal, privacy, and safety impact can raise the tier even when a code change appears small.

Definition of Done​

Before work is presented as complete:

  • acceptance criteria are met and the implementation has been reviewed;
  • appropriate QA and user acceptance testing have passed;
  • success and failure signals are instrumented, with an owner and evaluation date;
  • monitoring, staged rollout, rollback, and recovery match the delivery risk tier;
  • documentation and support guidance are updated where needed; and
  • remaining limitations or risks are named, understood, and accepted by the accountable owner.

Done does not mean abstract perfection. It means the smallest agreed outcome is useful, dependable, observable, and safe to place in another person's hands.

The ability to fix something later does not lower the standard for what ships now. Likewise, a low-risk reversible change should not inherit controls that do not improve its safety or learning value.

For the end-to-end product process, see the How We Build playbook. For frontend and backend tickets, see the technical ticket workflow.

Guidance type: Working agreement
Owner: Product, Design, and Engineering leadership