Skip to content

Definition of Done

Introduction#

This page provides details about the stages described in Flow of work.

Every stage needs a definition of done (DoD): the specific criteria a work item must meet before it can leave that stage. Without written criteria, items drift through a stage inconsistently, with different people having different ideas of what “done” means.

Backlog
Elaboration
Implementation
Deployed

The page covers the four core stages from the starting point workflow (Backlog, Elaboration, Implementation, and Deployed) along with three optional stages that teams often add: Ready for Implementation, UAT, and Ready to deploy. Use only the stages your team needs. If your workflow includes other stages, such as a separate test or approval stage, define your own exit criteria for those too.

This page explains the suggested exit criteria for each stage, illustrated with an example item followed through the workflow, and how the criteria vary for different types of work item.

Suggestions

The definitions outlined here are suggested defaults. You are encouraged to adapt these to your needs and context. They belong to the team, and the retrospective is the best place to revise them.

Backlog#

For items to be added to the backlog, they need a statement of what is required, for whom, and why. For user stories, 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>.

Enablers are better described in terms of the risk they reduce or the opportunity they enable, and spikes by the question they need to answer. See Variations by item type.

An item leaves the backlog when it is at the top of the ordered list, the Product Manager confirms it is still wanted, and it isn’t waiting on the findings of an investigation.

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.

Elaboration#

Items are pulled into Elaboration from the Backlog when team capacity and the WIP limit allow. This is where the item is enriched so that it is clear exactly what the aim is, roughly how it will be done, and how it will be validated.

Elaboration usually starts rough and gets progressively more detailed: draft acceptance criteria and hand-drawn sketches first, then edge cases, specific technical decisions, and designs at the fidelity the change needs.

To move from Elaboration to Implementation:

  • Acceptance criteria (ACs) are written, including non-functional ACs, edge cases, error cases, and anything explicitly out of scope.
  • The ACs are agreed between the product, development, and test perspectives, with the designer involved where the item changes the user interface.
  • The technical approach is detailed enough for implementation to start, referring to specific modules, components, or versions of third-party dependencies where relevant. Important technical decisions are recorded on the item with their reasoning. This should answer questions that would otherwise stall implementation, without restating the obvious.
  • Where it isn’t obvious how the ACs will be tested, a test approach describes how they will be proven, and at what level. See From ACs to tests.
  • UI designs are taken to the level of fidelity the change needs, consistent with the agreed conceptual model and its user journeys, and including empty, loading, and error states. Where the item uses existing design system components, an annotated wireframe may be enough; new patterns and components need high-fidelity designs. See design systems.
  • Dependencies that could block the item part way through are identified, and either resolved or scheduled so they won’t.
  • Where regulatory or compliance assessment applies, it has been done against the ACs, rather than left until after implementation. See Separate user acceptance testing stage?
  • The item has been considered for vertical splitting, and split where possible.
  • The team has estimated it in story points. Items larger than 8 points should ideally be split further, with 13 as a hard limit.

With just-in-time elaboration, it’s still worth writing all of this down, even if the person leading elaboration goes straight on to implement the item. Writing is a great way to clarify thinking and spot any areas which are still woolly. The written record also guides testing, and guards against unexpected absences.

Items that need investigation#

Sometimes it becomes clear that a design decision can’t be made confidently without further investigation, such as user research or a technical spike. When this happens, split the investigation out as its own item, and return the original item to the backlog. The investigation item goes through the stages in its own right, and the original item comes back into Elaboration once its findings are available.

Example item leaving Elaboration

When the item was first elaborated, it was split into two slices: entering an address manually, then adding postcode lookup. The manual entry slice has been delivered, and this is the postcode lookup slice.

Acceptance criteria

  • 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 I am told the postcode isn’t valid.
  • Given I am in the new address dialogue, when I enter a valid postcode that returns no addresses, then I am told no addresses were found and I can enter the address manually.

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, 400ms 99% of the time, and 10 seconds 99.9% of the time.
  • Given the postcode lookup service is unavailable, when I search for a postcode, then I am told lookup isn’t currently available and I can enter the address manually.

Out of scope

  • Editing or deleting saved addresses, which are separate items.

Technical approach

An earlier pass found that the choice of postcode lookup service needed investigating, so a spike was split out and this item returned to the backlog until it completed:

Spike: select a postcode lookup service.

The spike recommended self-hosting an open-source postcode lookup service. The address dialogue will call a new lookup endpoint in the address API, which queries the postcode service running as a container alongside it.

Test approach

  • Unit tests for the dialogue’s UI logic and postcode validation.
  • Code-level integration tests for the lookup endpoint, against the postcode service running in a container in CI, including the behaviour when the postcode service is unavailable.
  • One end-to-end test of adding an address using postcode lookup.
  • A load test in the pipeline to validate the response time AC.

Estimate

5 story points.

Designs

Example user interface sketch

Ready for Implementation#

This stage is optional.

Ready for Implementation is a wait stage, used by teams that elaborate items up front rather than just in time. This is usual for teams that work in iterations, because items need to be elaborated and estimated before they can be planned into an iteration.

Nothing is done to items in this stage. It is a small buffer of elaborated items, and an item leaves it simply by being pulled into Implementation, or selected for the next iteration. Keep the buffer small, with a WIP limit of around one iteration’s worth, or what the team gets through between elaboration sessions.

Implementation#

For most items, this is where the bulk of the effort is spent. If the item has been waiting in Ready for Implementation, start by checking with the Product Manager that its ACs and approach still hold.

An item is done when:

  • Production code changes meet the functional and non-functional ACs.
  • Every AC is proven by testing at the cheapest level that can prove it. Logic is covered by automated unit tests, while UI and end-to-end automation is reserved for key user journeys, so the automated test pack stays fast and maintainable.
  • Feature flags are implemented if required to allow changes to be deployed without being made available to users.
  • Exploratory testing is complete, and any gaps it finds in the automated tests are addressed.
  • 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 and load testing, run as part of the pipeline wherever possible, are fixed.
  • Any issues found during security scanning (such as with OWASP ZAP) are fixed.
  • Peer review by members of the team is complete, whether through pull requests, pairing, or ensemble working, and any issues found are fixed.
  • Where the item changes the user interface, the designer has reviewed the built result and any issues found are fixed.
  • The Product Manager has accepted the item. Involve them throughout implementation, by showing them work in progress, so that acceptance confirms what they have already seen rather than acting as a gate at the end.
  • Any follow-on work or enhancements identified are captured as new backlog items, rather than added to this one. See Items keep moving backwards.
  • Code is merged.

With Continuous Deployment, merging deploys the change to production automatically, so the item moves straight to Deployed. Otherwise it moves to UAT or Ready to deploy, if the team has those stages, in that order. Because UAT validates changes before they reach production, it doesn’t combine with Continuous Deployment.

UAT#

This stage is optional.

A separate user acceptance testing (UAT) stage can earn its place where expert users validate changes, such as for internal products whose users are part of your organisation, or B2B products with key strategic clients. It is not usually the right way to meet regulatory or compliance needs, which are better assessed against the ACs during Elaboration.

An item completes this stage when:

  • The expert users have tried the change in a UAT environment, in the context of their real ways of working, and confirmed it meets their needs.
  • Anything found that means the item doesn’t meet its ACs is fixed.
  • Anything else found, such as enhancements or missed needs, is captured as new backlog items.
  • Where the change affects how people work, the expert users are ready to explain it to their teams.

UAT involves a hand-off to people outside the team, so give it a WIP limit and keep an eye on how long items wait in it. See Work is handed off.

Ready to deploy#

This stage is optional.

Ready to deploy is a wait stage for teams whose production deployments are not triggered automatically by merging, such as teams practising Continuous Delivery rather than Continuous Deployment, or deploying in scheduled release windows. It stops the board from claiming that items are done when they are not yet in production.

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

Aim to shorten the time items spend here. See Releases are batched or scheduled.

Deployed#

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

Where feature flags are used, an item is Deployed once its code is in production, whether or not its feature flag is switched on. Releasing the feature to users, by enabling the flag, is a separate decision that doesn’t hold up the flow of work.

Variations by item type#

Not every item needs every stage or every criterion. Rather than keeping separate boards for different types of work, agree as a team which stages and criteria each type of item skips, and record those variations here alongside the stage criteria. See Different kinds of work need different routes.

Suggested defaults:

  • User stories follow the stages and criteria as described above.
  • Bugs are described in the backlog by what currently happens, what should happen instead, and how to reproduce it, rather than as a user story. The ACs describe the corrected behaviour, and implementation includes an automated test, at the cheapest level that can reproduce the bug, that fails before the fix and passes after it.
  • Enablers are described in the backlog by the risk they reduce or the opportunity they enable. Their ACs describe an observable outcome, such as no known high-severity vulnerabilities in a dependency. They may not need the Product Manager’s acceptance, and only need designer review if the user interface changes. Improvement actions from a retrospective are enablers too, and usually need little more than a clear statement of the outcome and an estimate before they can start.
  • Spikes are described by the question they need to answer. In Elaboration, the team agrees the question and a timebox, expressed as a story point size. A spike is done when its findings are shared with the team, any decisions are recorded, and follow-on items are created or updated, including the item that prompted it, which can then be pulled back into Elaboration. It then moves straight to the final stage, because it ends with findings rather than a deployment.

Key points#

  • Every stage needs written exit criteria. Unwritten criteria drift.
  • Backlog items only need what, for whom, and why. Detail is added in Elaboration, as late as is practical.
  • An item leaves Elaboration with agreed ACs, a technical approach, a test approach where needed, designs at the right fidelity, and an estimate.
  • If an item can’t be elaborated without investigation, split out a spike and return the item to the backlog until the findings are available.
  • Product Manager acceptance is part of Implementation, not a separate gate.
  • Implementation ends with merged code that meets the ACs and the team’s quality bar.
  • Done means deployed. An item that is merged but not deployed is still in progress.
  • Only add optional stages such as Ready for Implementation, UAT, and Ready to deploy where your situation needs them.
  • Agree how the criteria vary for bugs, enablers, and spikes, and record those variations explicitly.

Mistakes to avoid

  • Treating merged as done. Nothing has any value until it is in production.
  • Elaborating too far ahead. Detail added weeks before implementation goes stale, and is wasted if the item is reprioritised.
  • Leaving items in Elaboration while a spike runs. Return them to the backlog, so they don’t occupy a WIP slot while they can’t progress.
  • Treating Product Manager acceptance as a gate at the end. Involve them throughout, so there are no surprises.
  • Growing items to absorb everything found along the way. Fix what stops the item meeting its ACs, and capture everything else as new backlog items.
  • Copying the definition of done onto every item’s ACs. It lengthens the list and buries the criteria specific to the item.
  • Adding stages without exit criteria. If you can’t say what it takes to leave a stage, it isn’t well defined.
  • Criteria nobody revisits. If items keep bouncing back, or problems keep escaping to production, review the criteria in the retrospective.