Skip to main content

Accept the work

Confirm that the published change does what the ticket promised. This stage is human testing and review: pull-request review, QA, and user acceptance against the ticket's acceptance criteria.

Engineering already ran automated and published-branch tests. Product and Design perform user acceptance testing across the complete experience and its Builder options, as described in How We Build.

Prerequisites​

  • Published-branch tests have passed on the current source-code and Builder branches.
  • Acceptance criteria are visible on the ticket.
  • Reviewers and testers can access the same published artifacts named in the pull request.

Review and test against the criteria​

  1. Review the implementation on the pull request. The change is not accepted from local work or an unpublished Builder state.
  2. Exercise the expected behavior and the ticket's acceptance criteria in the approved test environment.
  3. Run the QA and user-acceptance checks required by the delivery risk tier. Contained, reversible work needs lighter evidence than customer-visible or difficult-to-reverse work.
  4. Check important failure paths, permissions, empty states, and regressions that acceptance criteria call out.
  5. Record who tested, what passed, what is limited, and which commit and Builder branch were used.

Use the Definition of Done items for review, QA, UAT, and acceptance criteria. Release still has to place the change in production and close remaining operational conditions.

Acceptance checklist​

  • The pull request reviews the same published branches that were tested.
  • Acceptance criteria on the ticket pass.
  • Required human review of the implementation is complete.
  • QA and UAT required by the risk tier have passed.
  • Remaining limitations are named and accepted by the accountable owner.
  • The pull request is approved for the team's release process.

When acceptance fails​

Return to execution. Correct the product, tests, or plan; publish new branches; repeat branch testing; then repeat this stage. Do not accept an earlier commit or Builder branch as a substitute.

If acceptance fails because the criteria are wrong, return to detail or planning and update the ticket before more coding.

Expected result​

Human review, QA, and UAT show that the published change meets the acceptance criteria. The work is ready for a production release decision.

Next: Release the work.