Skip to content

Definition of Done

Introduction#

This page provides details about the stages described in the Software Delivery Lifecycle (SDLC).

The Definitions of Done (DoDs) described here define each stage by giving specific criteria that work items must meet to proceed to the next stage.

These suggested DoDs are for the favoured just-in-time approach. If just-in-time elaboration is not used, then the DoD for the Ready stage becomes the combination of that plus that listed for the Elaboration stage.

Backlog#

Since Backlog is the first stage, it needs a definition of ready, as well as a definition of done.

Backlog Definition of Ready#

For items to be added to the backlog, they just need a statement of what is required, for whom, and why. The most popular format, and a reasonable default, is the “As a/I can/so that” form:

As a <persona>, I can <do action>, so that <desired outcome>.

Example item in Backlog

As an existing customer,
I can add an alternative delivery address,
so that I can easily choose which address to have my delivery sent to without needing to re-enter it every time.

Backlog Definition of Done#

These details need to be added for items to be moved to Ready:

  • Rough Acceptance Criteria (ACs) in “given/when/then” form with an optional extension shown in square braces:

    Given <initial state>, when <action is taken>, then <observed outcome> [and <other observed outcome>].

  • Rough visual designs (if applicable) — hand-drawn sketches are fine at this stage.

  • Non-functional ACs (also called NFRs — Non-Functional Requirements), also in “given/when/then” form. This form encourages a user-centric approach that helps validate the relevance of the NFRs.

    Example NFRs
    • Given there is a baseline load of 100 requests per second, when I make a request, then I get a response in under 100ms 95% of the time and under 200ms 99% of the time.
    • Given I am sending a request to update my username, when the name field contains SQL injection code, then it is stored safely without executing the code.
    • Given the primary and secondary databases are both operating normally, when the active database fails, then the secondary becomes active and responds to requests within 10 seconds.

  • High-level technical approach.

  • High-level test approach.

As the item is examined more closely, it often becomes clear that it can be vertically split and this should be done before proceeding.

It may also become clear that certain design decisions cannot confidently be made without further investigation such as user research or technical spikes. This is best handled by splitting out investigation tasks which should be taken through the rest of the stages to produce insight that can be fed in. This is illustrated in the example in the Ready stage.

Ready#

Ready is a wait stage: nothing is done to items in this stage, it just acts as a holding area for items that have completed the previous stage but not yet been pulled into the next.

Example item in Ready stage

Acceptance criteria

  • Given I am on the account settings screen, when I choose “Add address”, then a dialogue is shown that allows me to enter an address.
  • Given I am in the new address dialogue, when I enter a valid postcode in the postcode search box, then a list of possible addresses is shown.
  • Given I am viewing the list of possible addresses for the postcode I entered, when I choose an address, then the address details fields are populated with the correct parts of the address.
  • Given I am in the new address dialogue, when I enter an invalid postcode in the postcode search box, then an error is shown.

Non-functional ACs

  • Given I am in the new address dialogue, when I enter a postcode in the postcode search box, then the list of possible addresses is displayed within 200ms 95% of the time and within 400ms 99% of the time and within 10000ms 99.9% of the time.

Technical approach

Postcode lookup options include using a SaaS provider or self-hosting an open-source or commercial solution. More investigation is needed so we should split out a research/spike task to identify options and validate them:

Spike: select a postcode lookup service.

This spike must be completed before this item can proceed.

Test approach

  • Unit tests for simple UI logic.
  • Code-level integration test against locally running postcode service in containers in CI.

Designs

Example user interface sketch

Elaboration#

Items are pulled into Elaboration from the Ready stage when team capacity (and WIP limit) allows.

To move from Elaboration to Implementation:

  • All of the items added to move items into Ready need to be refreshed, to ensure they are still relevant, and elaborated by working into any remaining edge cases.
  • The high-level technical and test approaches need to be made more detailed, such as by referring to specific classes, modules, or versions of third-party components.
  • The UI designs need to be mocked up properly in Figma or similar.

Again, consider whether the item can be sliced more finely and do so before proceeding.

Implementation#

For most items, this is where the bulk of the effort is spent. An item is done when:

  • Production code changes meet the functional and non-functional ACs.
  • Feature switches are implemented if required to allow changes to be deployed without being made available to users.
  • Appropriate unit and other automated tests are implemented to validate ACs.
  • Observability is provided, such as via logging and additional metrics.
  • Code is commented to explain why it works as it does and project documentation is updated.
  • Code is refactored for future maintainability.
  • Any linter, static code analysis, and dependency version issues are fixed.
  • Any issues found during performance/load testing are fixed.
  • Any issues found during security scanning (such as with OWASP Zap ↗) are fixed.
  • Any issues found during peer review are fixed.

Depending on the team’s ways of working, this stage may conclude with code being merged, or this may be delayed until the UAT stage is complete.

UAT#

An item completes this stage when:

  • Exploratory testing is complete and no gaps in the automated tests need to be addressed.
  • The Product Owner is satisfied that the feature can be deployed as-is.
  • Any follow-on work required is captured as new backlog items.
  • Code is merged unless already done.

Ready to deploy#

The only thing required to complete this stage is a successful deployment to the production environment.

Deployed#

Items in this stage are complete with nothing left to do.