Delivery - Definition Of...

Here are default example definitions of when a work item is ready for the team to work on and complete ("done"). These can be taken as a starting point within a new team, or when a team is at the size where it needs them.

These should be living documents within your teams, changed to suit your specific needs and environment, and agreed with the team in advance of any implementation.

Definition of Done

A Definition of Done (DoD) is a shared set of criteria that allows us to pinpoint exactly when a specific backlog item can be considered to be complete. It is a very powerful tool for aligning a team on what good looks like, and preventing re-work.

Without a DoD, items can drift in terms of quality and consistency. It is compelling to have a collectively-agreed set of items that define when a work item is complete. This will help remind both teams and individuals of the responsibility associated with each work item.

A good example of a Definition of Done is provided below. This example should be amended to fix the needs of the team, and should be a living document, adapted as the team grows, learns and improves.

Definition of Done: Example

Acid Test: Is the solution running and in production? i.e. there is no further work required by anyone.

• The solution meets the acceptance criteria.
• The solution builds without errors or warnings.
• The solution has automated unit, component, contract, end-to-end, and performance tests.
• All automated tests pass in a staging environment.
• The solution has passed code quality (code analysis) and code style standards (linting) checks.
• The solution has been code reviewed or fully pair-programmed.
• Code, configuration, design, diagrams, API documentation, and README are up-to-date.
• The solution has automated build, release and deployment.
• Observability is in place (e.g. logging, monitoring, tracing).
• All infrastructure changes are in code (IaC).
• The solution is released to production.

Definition of Ready

A Definition of Ready (DoR) is a common set of criteria that every work item must meet. It allows a team to evaluate whether a specific backlog item is defined in enough detail and estimated fully, in order for the team to be able to plan their work accordingly. It is an effective tool for a delivery team, helping drive a consensus within the team on what work should look like, and supporting consistency in business outcomes. It is especially useful for protecting a team experiencing poorly-defined requirements.

Without a DoR, unfinished or unrefined work items can end up being completed by the team. Misunderstandings or gaps in functionality can cause wasteful re-work or scope creep. This extra work will increase overall lead time, potentially increase blocked time, reduce throughput due to additional discussion and confusion, and overall reduces value delivered over time.

To fix these issues, we can write and agree to a Definition of Ready across the whole delivery team. This DoR document can be different across development teams or common across the project; it's entirely down to individual preference. We'd recommend trying to stick to a largely common DoR, as this will help facilitate the movement of individuals between teams.

A good example of a Definition of Ready is provided below. This example should be amended to fit the needs of the team, and should be a living document, adapted as the team grows, learns and improves.

Definition of Ready: Example

Acid Test: Is the work item fit for development, i.e. can the team commit to delivering it within one sprint?

• The work item has a clear title, narrative and business context.
• The work item has a set of acceptance criteria written as true/false statements.
• The work item is small enough to fit into one sprint.
• The team clearly understands the business value/user need/expected impact.
• If applicable, visual designs and other assets are final.
• The team has estimated it.
• The team understands how to build it.
• The team understands how to acceptance test it.
• The team understands how to performance test it.
• The team understands how to demo it.
• Dependent teams (Marketing, Legal, Risk, Operations) have signed off on it.