Every team, whether you are practicing agile or not, regardless of platform or language, should really have some Definition of Done. What does it mean for a story/feature/defect/whatever to be “done?” What things have to happen to achieve “done” status? Defining these things will help with estimating effort, and it may also help increase the quality of your product. Here are a few of the things I look for in a Definition of Done.

Note: I’m going to talk in terms of ‘stories’ for the remainder of this article, but most of these are still applicable regardless of what you call your unit of work.

Code Is Complete

This one is a no-brainer. Before a story can be considered “done,” all code must be complete. By complete, I mean in its final, polished, refactored form. There should be no lingering TODO comments except to identify future work that is out of scope, and there should be no giant commented-out blocks of code.

Code Is Consistent With Established Styles

Each team should strive to establish and adhere to some general styles. For example, everyone on the team should put braces in the same place, private fields should be prefixed with an underscore, that sort of thing. By keeping styles consistent, you’ll eliminate mental shifts that occur when going from one area of the codebase to another. You will also streamline development (no more thinking about which of the 20 different styles to use), improving productivity for everyone.

High unit test coverage

Your team is doing Test-Driven Development, right? If not, check out this post on why you should investigate it. Even if you aren’t doing TDD, hopefully you are least performing Test Later Development. All new code should have very high unit test coverage. If you’re already preparing your “But high coverage doesn’t guarantee quality!” comment, you can relax. I agree completely, high unit test coverage just tells you one thing: that you have high unit test coverage. It does not tell you anything about the quality. However, if you are doing testing the right way, and if you are doing peer reviews (see my next point), high test coverage can indeed give you confidence that new code works, that existing code is still working, and that any future regressions will be quickly identified.

Story peer reviewed

There is absolutely no substitute for a second set of eyes. Unless you’re religiously practicing pair programming, I strongly recommend that any team adopt peer reviews. No, I don’t mean you should schedule meetings around a projector where one developer tries to defend his work as the rest of the room tries to poke holes in it. Again, I’ve talked before about how I think peer reviews should be performed, so check it out if you need a refresher. A proper peer review process will help improve the overall quality of code, help spread new ideas throughout your team, and will ensure that at least two people understand how a particular story was implemented.

Story tested in a higher environment

This one is hopefully a no brainer. Someone (ideally the person that requested a feature or bugfix) should test out the change in a higher environment. By “higher,” I really just mean anywhere except for your local machine. If you have separate dev, staging, and prod environments, great, get someone to test out the change in your dev environment. Why is it important to test somewhere besides your local machine? Because testing it elsewhere confirms that the change was fully committed to source control and can be deployed to another environment. This may seem trivial, but have you ever forgotten to commit a JPG or CSS file? That sort of thing is unlikely to break your build or cause tests to fail, but it will show up when someone tries to actually use the feature that depends on the missing file.

What else?

Those are the standard ones that I think should be part of any Definition of Done, but there are certainly going to be others that make sense based on how your team works. For example, do release notes need to be updated? Do deployment procedures need to be reviewed? Consider all the steps that need to be performed to deploy a story to production, and verify that you’ve captured anything relevant in your Definition of Done.

For anyone out there who already has a Definition of Done, I’d love to hear how your definition stacks up against mine. Leave me a comment below!

About Matt Honeycutt...

Matt Honeycutt is a software architect specializing in ASP.NET web applications, particularly ASP.NET MVC. He has over a decade of experience in building (and testing!) web applications.
He’s an avid practitioner of Test-Driven Development, creating both the SpecsFor and SpecsFor.Mvc frameworks.

He's also an author for Pluralsight,
where he publishes courses on everything from web applications to testing!