Standards and the definition of done

  • Without standards there can be no kaizen, Taiichi Ohno.

Kaizen is a Japanese word that can be translated as “change for the better”. It’s widely interpreted as meaning “continuous improvement” when referring to process or flow.

As Taiichi Ohno (father of the Toyota Production System or TPS) highlights, in order to improve, you first need to have a baseline standard. From the TPS perspective, standards and the improvement of said standards, relate to two aspects:

  1. Process – the work carried out at a particular step on the production line.
  2. Flow – the overall flow through the production line from end-to-end.

So, if we’re to translate this to cross-functional product teams, determining their baseline standards can be achieved by asking them three questions:

  1. What defines an item of work and when do we know it’s ready to be worked on? This denotes the start of their flow.
  2. When do we consider an item of work completed? This denotes the end of their flow.
  3. What are the individual steps that are required to take a piece of work to ‘done’? This characterises each step and what that entails.

In this way, the team defines the process steps that take the product or features of the product to completion. This then becomes known as the ‘Definition of Done’.

It’s important to define done because it helps the team reach a mutual understanding of what an acceptable standard is. It also assists the team in an estimation of effort for a work item. For example, if the item of work is a User Story,  the acceptance criteria for the User Story plus the items on the Definition of Done have to be completed for it to be considered ‘done’.

So, where the acceptance criteria for a User Story can be used to gauge if you’re building the right thing, the Definition of Done is a way to gauge are you building the thing right? It defines the quality aspect of delivery.

In setting up a Definition of Done, or any form of working agreement, accept that not every eventuality can be foreseen or catered for. It should be considered as a ‘living’ document, something that will mature and change as the team process matures and changes.

If a potentially better way or working is found, it should be discussed with the group that are bound by the working agreement and a consensus (most people are happy) on whether to alter it should be reached. For most teams this happens during the retrospective meeting, but can also happen at any other time when the team gathers.

One final thought, when setting up a Definition of Done, and for working agreements in general, keep in mind the Agile Values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

This values will help the team form an appropriate agreement with an emphasis on ‘working’, rather than impeding. They should pay particular attention to the third value and in this instance instead of “Customer collaboration”, read just “collaboration”.

Contracts are generally inflexible, changes are not simple and to uphold them generally requires some form of policing. All very time consuming and should be avoided as much as possible, especially within a team.

Collaboration is inherently flexible and allows for change to occur more fluidly. It’s also self-policing, so no need for one individual to step away from the frontline, each team member has responsibility and is accountable for how things get ‘done’.