What is the definition of done?

Imagine, someone asks you to build a feature, you spend time figuring it out, you build the solution then proudly hand it back, it is now done… well, maybe not. 

Sometimes it’s just not as simple as saying that a feature is done, especially when you’re in the streams of business as usual, and you’re releasing updates continuously. 

So what exactly do we mean by “The definition of done”? 

When you compare it to other industries, or even general tasks that you need to do, it’s not so different to most. Take this article I’m writing for instance. You would think that the definition of done for this is to write an article about the definition of done (Gosh that’s so meta). But it doesn’t really end there because there are elements that need to be considered once the “feature has been completed” 

• Does it have enough words?
• Are there any mistakes?
• Has it been uploaded on to the website?
• Does it pass company policy? 

So you see, I’m not just writing an article and then it’s done, it’s ensuring that all of the other “non-functionals” are met too. 

Let’s turn our attention to the world of development and delivery. When you kick start a team within product development, you get a very large set of features and user stories on the board of your choice (be it Azure DevOps, Jira, Trello etc.) and you start bulking it out with acceptance criteria that the developers can build against and the testers can test against. 

Once you set out the standards in which the team work, such as tooling, communication etc, you then set about asking the question, “what is our definition of done?” and in most cases, it’s not as simple as, “well, once the acceptance criteria is hit, then it’s done.” In most businesses you should be looking at these areas within digital product delivery: 

• The feature meets all of the acceptance criteria outlined in the ticket.
• It hasn’t broken any other areas on the product as a result of deployment.
• The feature meets any non-functional requirements such as browser compatibility and accessibility.
• The feature / content passes company compliance and is safe to go live. 

The problem with most rapid delivery teams is that they want to hit their sprint goals that their aim is to get the cards from the left to the right as quickly as possible, so they can release the feature at the end of the sprint to keep people happy. But the danger is the definition of done seems to be out of mind when trying to rush things through and corners get cut, corners that could cost a lot if the steps aren’t followed. 

How do you get around it? 

There are 2 areas to consider:

• We already have our product live, and we’re making continuous improvements.
• We don’t have our product live yet and we’re building it ready for an MVP release. 

If you’re running continuous improvement (a), then it’s 100% important to make sure that the you’re hitting the definition of done and you add it to the acceptance criteria, so when the feature is ready to go live, it’s hit all of the acceptance criteria which includes the non-functionals. 

If your product is in development and isn’t live yet (b), then there’s a bit of leeway, the urgency of ensuring non functionals are hit, whilst you’re in the process of building the product from the ground up can sometimes be counterintuitive, because certain elements aren’t there. But adding in audits along the way to create tickets to rectify them, is a good way to make sure that you’re still complying to certain non-functionals. 

It’s the slowest thing to do 

I’ve seen it many times when working on products, specifically within the financial services sector, the features themselves are actually easier to build and deploy than chasing the right person in the business so you can get a piece of content signed off for compliance.

It’s really important in the finance industry that the changes are compliant otherwise that could mean an expensive bill should it not meet the requirements, and I’m sure it’s very similar to other regulated industries too. 

How do you speed it up? The best way to do this, is to make friends, I’ve said it before about building a team ethos certainly within Scrum Agile, you win as a team and you fight challenges as a team, there isn’t one person that’s more important than the rest in these victories. Bringing someone in to the fold from the compliance team, to join the stand ups to keep them in the loop, so they can help feed in to the development of the feature and the content. So when someone says, “Has this met our definition of done?” you can confidently say “Yes! Yes it has!“ .

 This has worked really well in all cases that we’ve done this. And it also makes them accountable when they join the stand up and someone asks “why is this card blocked?”, no one wants to be a blocker, trust me. 

In summary, they’re hidden and they can sometimes trip you up because they’re easy to forget about them, ensure that your definition of done is drilled in to the team so they’re all advocates of achieving the right product and make friends with the people that can sometimes cause you the most difficulty when you just need speed and bring them in to the team to make them feel involved.

Hero image by Kyle Glenn