“I finished!” — what does it mean?

Definition Of Done is one of artifacts that agile methodologies introduce. At first glance it seems quite easy and… as such it does get as much attention as it deserves and gets misunderstood quite often.

Most teams I’ve seen start with “Uncle Google” to find some examples and then copy-paste it somewhere in own repository so that they have something to show. The problem with this approach is that as a result team gets DoD from some random group of people they don’t even know and don’t identify with. Chances are that this group got their DoD exactly same way.

So there’s some document somewhere in repository. Try to ask your own colleagues about it and don’t be surprised if you hear this kind of answer. Moreover, you can consider yourself lucky if you’ll hear where exactly this document is — which folder in Sharepoint, what’s the ticket number in JIRA, etc.

However the ideal Definition of Done should be considered team’s mission statement. It should briefly but precisely describe the way team approaches tasks and what values it believes in. This can consist of any area of expertise we struggle with in software development: technical, customer relations, engineering good practices and so on.

But, like any other definition this should be short and easy to remember. The purpose of DoD is to remind team members their own values so you don’t need to say how to do code reviews, QA testing, what does coding standard mean (or why it’s valuable) — these terms are clear to anyone who works in our industry.

And for people who don’t — I mean customers — they should be introduced separately because each of them deserves separate discussion.

In Sitewards, we truly believe in our company mission. From time to time we have a quick exercise during meetings: we get a mission with a few words removed and we get a few minutes to fill them. I strongly encourage you to try this with your team: get your Definition of Done, replace some random words with question marks and ask your colleagues to fill them.

Naturally, exact definition might change with time along with experience you gain. It should be also adjusted to specific project to reflect customer beliefs — after all he shares the ultimate goal of producing good product with you and as such he actually is a team member.

Sometimes you might want to reflect the way your team work by introducing multiple stages of software life cycle. In Scrum this also is described as “triple D” — Done-Done-Done. Exact meaning of each Done will differ but could be for instance something like this:

1. Feature reaches first “done” when it’s precisely described. All acceptance criteria are there and everyone has common level of understanding what actually needs to be realized. That would be just Done.
2. Another “done” might be a state when development of the new feature is ready to deploy. This would mean all testing — both automated and manual — that organisation requires. We can say that our work is Done Done.
3. Last and ultimate “done” might mean that the new feature is actually delivered to the final user and confirmed it’s working as expected. Only when final user get benefit from new feature our work is actually Done Done Done.

This approach is fine but use it as appendix to your basic Definition of Done. Just like company strategy extends and details for its mission, DDD could elaborate on team’s DoD.

To summarize, Definition of Done should be a motto of how team wants to work. It should be clear, precise statement that team really identifies with. And as such it’s really worth to invest some time to discuss and form very own form instead of just googling one.