Waterfall teams that finally get some customer feedback are usually in for a rude awakening. All of a sudden, people start to complain. Quality is low and the scope is underdeveloped.

Old school managers would stress the need for better analysis. After all: low quality in, low quality out. Since every feature is lacking small parts, we need to spell it out more.

These days, everybody is Agile, so we don’t do that anymore. Your friendly neighbourhood Scrum Coach has come up with a better plan: the Definition of Done.

The DoD is an extra step on the Kanban board. Before a ticket can be dragged to Done, the team goes through a checklist: Did it meet the acceptance criteria? Has it been reviewed? Has it been documented?

On paper, it looks like a good idea. On paper, Russia doesn’t look that far from here.

In reality, the Definition of Done is a flawed concept.

It starts out with a problem: the documentation is never up-of-date. Some manager decides that this is because developers don’t like to write docs and comes up with the genius idea of adding that DoD step. Before a ticket is “Done”, it has to be documented.

Notice how the burden is completely on the dev team here. They already have a backlog crammed with User Stories written by someone else and now they have to “remember” to document every single one of them. Also, notice how estimates didn’t go up and the deadline didn’t shift. They just magically need to make it happen. This is a freebie for management.

The Broken Window theory states that once you add one Acceptance Criterion to the Dod, the next one will follow soon. So, the manager adds “It should be tested in UAT before being Done”. That makes sense, no?

While it’s easy to add stuff to the Definition of Done, it gets gradually more difficult to meet those demands. A dev ticket becomes a bureaucratic mess. Productivity and morale go down.

The idea of a Backlog and a User Story is that they should be as small, lightweight and simple as possible. They also have a very limited shelf life. Weighing down stories with Acceptance Criteria and checklists will harm your flow.

Add a ticket “Update documentation for release v2.1” instead of a DoD step. Set up a Continuous Deployment pipeline instead of adding a “Deploy to UAT” checkbox to the AC.

Instead of having a Definition of Done, have a small, almost empty backlog and have developers add their own small, short-term tickets at the beginning of the iteration. If there are things that really need to be done at the end of each ticket, automate them.

As a team leader, your job is to build an environment where your developers can be productive. Don’t slow them down with red tape. Make it easy for them to get to Done.