This article addresses two themes: how to agree and set team standards which result in high quality, reliable and observable systems, and how to know when a work item is finished and ready to be shipped.

Both can be tackled by the team agreeing a common set of non negotiables that each work item must adhere to and importantly helps the team understand when the work is complete. It forms alignment among the team around what good looks like and holds them to account to only merge and deliver quality solutions. This tool & way of working is called the Definition Of Done.

Quoting the Scrum Guide:

The Definition of Done includes all of the characteristics and standards an Increment needs to meet in order to be released.

In other words, the criteria forms a checklist that defines what is needed for work to be shipped.

If the criteria is met:

  1. the outputs produced should be consistently at a high standard.
  2. the work is finished and can be shipped.

When Is Work Considered Done?

Sometimes engineers can be hesitant to merge code and release features. It may be caused by a lack of confidence or it could be they’re unsure if they have fulfilled the original request. The Definition of Done can quell these opinions as the objective criteria will answer the question of is it done?.

Depending on your criteria, is could be Done when the request is in the user’s hands or it could be when it is ready to ship. That is a team and organisational level decision, for example Change Approval Boards can prevent Continuous Deployment and so work is Done when it is in a Staging / Non Production environment and only process is blocking the release.

Importantly the foundation of Done should be when the original request has been fulfilled; the change requested is complete and, in the example above, is in the users’ hands. This should be the first item on the list.

Standards and Quality

Engineers have varying levels of experience and standards, they do not always correlate. An experienced engineer doesn’t necessarily produce high quality code and a junior with the right guidance may already know what good looks like.

When building products and services, we want to ensure the customers have a delightful experience, one that is consistent and reliable, without service interuption.

Naturally the customer expectation becomes a driver for the business’s expectations and this filters to the team as features and qualities in a system. To meet this expectation the team can agree and adopt ways of working which guide how software is delivered and set the minimum accepted standard.

Example: Observability

To have continuity of service and maintain trust with users, we need to know when things go wrong and fix them quickly. A team can build in observability with monitoring and alerting which notifies the team of any unexpected behavior. Logging and tracing can help us find the root cause of an issue and provide vital information to fix it and restore service.

Here we have identified an essential component which should be applied to the whole system.

This must be included in any work item completed. This can be added to the Definition of Done.

Example Definition Of Done

The below example is robust set of criteria I have been using in part for a number of years. It is meant to be holistic but importantly, useful. Not all teams will benefit from all of the points but it has served me well.

  • Acceptance criteria has been met
  • All changes are in source control
    • Every commit is sensibly named
    • Changes have been accepted via Pull Request which included a link to the original ticket
  • There is evidence of peer review or the changes have been pair programmed
  • All changes have automatic formatting and linting applied
  • All changes build without errors or warnings
  • All changes pass existing tests
  • New functionality / code meets the team testing standard ie unit, integration, regression
  • There are no known vulnerabilities in any dependencies used
  • All changes are observable: they have monitoring & alerting in place, including tracing and instrumentation.
  • All builds and deployments are made through automated Continuous Integration and Continuous Deployment pipelines
  • All changes are in production, even if they are not used
  • Naming conventions are in plain english avoiding engineering parlance (phrases) and provide clear context to the reader
  • All changes are documented in the following ways:
    • Code as documentation
    • Each change has a corresponding description in the Pull Request that explains the new functionality
    • Significant changes are documented in READMEs and Decision Logs
  • At least one other member of the team is confident they understand the changes made and how to operate them.

Depending on your Definition of Done, some of the points on the checklist can be automated - for example automated code formatting and dependency vulnerability scanning.

This definition is almost too detailed. The sub-bullets can be separated into other ways of working patterns but have been included here as a guide and for context completeness.

Wrap Up

To help a team move quickly and deliver top class solutions, a good Definition of Done can provide confidence that they are doing the right thing, have fulfilled the request to it’s fullest and to the highest standard.