Skip to main content


Tomasz Liberski
Definition of Done

Show me your Definition of Done and I’ll tell you who you are

Analyzing a company’s Definition of Done (DoD) can tell you a lot about their work ethic and what they put the ‘quality’ sticker on. I’ll explain a few concepts about and around DoD to make it clearer.

First question: do they have a DoD?

There are some vendors who don’t have a DoD at all. That usually doesn’t spell anything good. If you’re set on signing a fixed-price contract (which I don’t recommend for software development), then it’s likely the contract will include certain definitions. However, there are some things that are hard to put into that initial agreement you sign. This makes them tough to enforce on an agreement level.

If you’re using Scrum/agile practices, then a missing DoD document is odd and should be worrisome. Are the quality criteria arbitrary, depending on a particular developer’s current mood? Or perhaps – the list exists, but you’ve never seen it? Ask yourself why that could be the case. The answer can’t be good.

Scrum

The DoD is a frequent element of agile practices. Just a word here, though. Scrum doesn’t dictate what exactly your Definition of Done should be, it just suggests that the functionalities that the team delivers in a sprint should meet a set of criteria you’ve established together. It’s a form of agreement between the team and – usually – the Product Owner on the client side.

What is it?

It’s basically a set of expectations software has to live up to. If it doesn’t meet the criteria you’ve established with your team, it can’t go to production. Let’s say you can determine two things out of the triangle of scope, quality and time. We’re establishing a firm timespan of a scrum iteration and constant (high!) quality. That’s the basis for DoD.

Some general rules

You usually establish code and functionality checks, and code coverage percentage, so that you can objectively state how well-tested the code is. Is it implemented according to all user requirements? Has it built and have all tests passed locally? Last but not least, you look at performance and security issues – and, of course, the code must go through a code review.

Don’t confuse it with the Definition of Ready, which is a set of minimum criteria that a particular item in your backlog (or your list of tasks or features you want to have) must fulfill before it gets moved to development. DoR is designed to weed out badly defined tasks.

The DoD document isn’t a contract per se, but it’s sometimes referred to as such. One of our teams (working on one of our bigger, scalable projects) recently printed out the DoD list and everyone signed it, client and team, old school style! This is just to underline how seriously this document is treated.

definition of done

Transparency is key!

As a client, you shouldn’t just be familiar with the Definition of Done. You should understand it. If there’s anything that you don’t quite get, it’s the software partner’s job to explain it to you. After all, you’re agreeing on a common definition of quality, and quality that can be – and will be – checked and measured. Working with agencies that obscure the meaning of certain phrases or are deliberately vague about what ‘done’ means will be problematic.

Maintaining your documentation in order is also a part of the Definition of Done. There are other transparency issues connected indirectly with the DoD, such as accountability, transparency when it comes to reporting, not to mention a clear process.

Other matters of quality

If you’re asking your vendor about quality and what is means to really be ‘done’, ask them about code reviews and testing. Code reviews and audits are derivatives of DoD. Another developer should evaluate the feature you want – a second opinion is necessary. This is an ongoing process. Software testing is part of Quality Assurance. Good automatic and manual tests will ensure nothing blows up in your face once you get your feature released.

A really good software development offer should be complemented with design and hosting services, experience with monitoring and performance scaling, as your application is designed to grow, right? If you’re at the starting point, product design (the whole package) is certainly a nice thing for an agency to have.

If you’d like to grab our Definition of Done list (we’ve worked hard on doing it right), drop us an email at hi@espeo.eu with ‘DoD’ in the title.

Share:Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on Pinterest

Like what you see?

Get in touch! We'll respond quickly, and we'll keep your data confidential.