Software developers have a reputation for being somewhat careless when answering the question “are you done with this feature”? In most cases the answer comes “Yes, Done” then the developer meant to say “Programming is done but…” and the interest point of the answer the world wants to hear is the state of “Production readiness” including testing, bug fixing and so on. Here comes the “Definition of Done” that needs to be agreed among the involved persons within a Product development process.

Definition of Done aka DoD works different way for several Agile teams, but serves the same ultimate goal for everyone. It should be a satisfaction checklist for software development teams to handover a shippable feature at production. In Agile practices, a shippable feature can be an independent unit of deliverable that is done according to Definition of Done.

In context of a developer, I strongly believe everyone should have his or her very own written form of “Definition of Done” for particular projects, even you are doing freelance or teaming up with others. Before digging into personal DoD, lets learn what others have as their DoD.

In our company at Vantage Labs, we are practicing Scrum since last five consecutive years successfully and each self organizing team settled their own “Definition of Done” at first place.

Here are two samples of “Definition of Done” collected from two diverse teams of products.
The first team deals with Web and Mobile based CRM, they have a decent set as the followings:

Code was implemented.

If required, Unit tests were written and pass.

Committed to source control.

Peer review is conducted; necessary improvements are made.

Deployed on stating server and ready for acceptance test.

QA Scripts developed or manual test scripts documented.

Functional QA was completed; conditions of satisfaction were met.

Bugs from QA resolved.

The second team works with English Grammar Engine and they have their very own set of procedures to meet the Doneness which are as followings:

A unit of work aka. Story is done when:

Code is implemented.

Code is checked into source control.

Code rebuilds from source control both on Windows and Linux.

The tests for defined benchmark sentences have precision over 80% and recall over 60%.

Results are documented on Wiki (benchmark sentences, performance).

The sprint (2 weeks of work for different feature completion) is done (it means that all the sprint stories can be deployed to production) when:

Pass the load test.

Regression tests are successful.

Pass the 5-essay evaluation by the editors.

The first team works with web development and has a classic set of Definition of Done that can be validated against most of their general purpose features while the second team works with backend component and has measurement oriented list in their definition. The first Definition of Done is the most widely used set around.

This context specific simple list of criteria can ensure software quality in a greater extent, as at the end of day the stakeholders will be using your delivered feature. This particular practice of Agile can be adopted separately in generic case as well by a single person. Note that better delivery is a choice.

Once we had a pretty large story on relabeling the whole platform, that includes adding newer translations, modifying existing texts, colors, buttons and layout alterations, these are the works you might consider as interface tweaking.