What the Heck is the Definition of Done?

You’re sitting in sprint review with your development team, and the product owner is presenting a new feature to you and the other stakeholders. Everyone is excited. You’ve been anxiously awaiting this feature. Maybe you have customers that have been expecting it, or better yet, you have a big sale that is depending on it.

As the product owner wraps up you say, “This is great! When can we get it in the hands of our users?” The look of enthusiasm and accomplishment on the team’s faces quickly disappears and they start to back pedal and explain that it’s not ready to go out the door. Everyone’s hopes are dashed because the work presented is not “done.”

What the heck happened? What does “it’s not done” even mean? When is it “really” done?

It’s important for everyone – the Scrum team and business stakeholders – to understand what we mean when we say, “This user story is done.” A definition of done ensures there is no confusion between what the Scrum team may believe is done and what the stakeholders believe is done.

In this case, there was an obvious disconnect.

The critical success factor for agile development is that completed stories are truly “shippable” at the end of each sprint, and the Scrum team is comfortable that the current product increment could be deployed to production within one sprint. If the team says, "We haven't written the online help yet," and it is expected that's a big miss.

You’ll want to create a clear definition to avoid repeating, "I thought you said it was done?"

Define What Done Means for Your Team

There is no one-size fits all approach for defining what done looks like. Start by defining and documenting done with your team. That gets everyone on the same page. What will it take to make you and the Scrum team comfortable that you're ready to put the product in front of end-users?

Putting the definition in writing forms an agreement between the Scrum team and business stakeholders. It's important to include everything that might be applicable even though certain user stories may not require all of the items on the list. The important thing is that all of the items are considered for every user story.

At Ascendle, we have our own definition of done. You may want to consider the following points for inclusion:

• Meets all Acceptance Criteria - The functionality works as described by the acceptance criteria in the user story.
• No Known Bugs - There are no known bugs in the new code.
• Peer Code Review - The code for the story has been reviewed and meets all coding standards.
• Unit Tests - Automated unit tests exist for the new functionality and all of them are passing.

Digging Deeper on Your Definition of Done

At your company, or in your industry, there may be additional items you can or need to add to meet the definition of done. Here are some you might want to consider:

• End-user Documentation – If your company provides end-user documentation as part of your product and it needs to be completed before your team can push new features or functionality out, you’ll want to include this in your definition of done. This may include online help, user guides, and any other materials such as video tutorials or internal support documents.
• Functional Requirements Validation – Your product might need to be tested on specific platforms or technology—for example iOS and Android for a mobile app or Safari, Chrome, Edge, and Internet Explorer for a web app.
• Regulatory Requirements – Depending on the type of application you are building or the industry you work in, this may include 508 compliance for accessibility to people with disabilities, HIPAA for those in healthcare, GDPR for privacy, etc.
• Performance – There may be performance standards that apply to every story, such as the ability to support a certain number of users or number of database records.
• Integration Tests – Many larger software products must coexist within an ecosystem comprised of many related systems. You don’t want to find out months down the road that the product doesn’t play nicely with others. Including fully integrated testing in your definition of done ensures every story is “certified” to work with other related systems.

The team should ensure all the items in the definition of done have been satisfied before presenting the story at a sprint review. Prior to that point, the product owner should ensure the development team has reviewed the list and ensured everything has been addressed.

What other ideas do you have for defining what “done” means? Leave me a comment below.

This post was previously published on the Ascendle blog.