When I first started out in engineering, people would talk disparagingly about somebody being a "ninety-five percent" guy. I had one for a boss. He would assign you a partially complete task saying it was ninety-five percent complete. You just had to do the five percent that took ninety-five percent of the time.

In Agile development, a task or story gets no credit until it's completely done. This is an important concept. Done is often a lot farther than it looks. A developer may write a bit of code that compiles and seems to work. He may think he's done, but he's not done-done. The team needs do develop a working agreement of what done-done means.

Here are some articles on the topic:

• Artem Marchenko's Definition of 'Done' discusses the need for such a definition and what it might include.

• Chris Sterling's Building a Definition of Done describes a story of un-Doneness, and talks about a method to decide on your team's definition.

• Payson Hall's Done and DONE-done points out that without a definition of done, you don't get done.

• Jeremy D. Miller's "Code Complete" is a lie, "Done, done, done" is the truth describes how less than Done-Done is pretty worthless.

• Aaron Ruhnow's Are We There Yet? lists his team's definition of Done.

• Derik Whittaker's Definition of 'Done' offers another definition of Done.

• Michael Nygard's A Dozen Levels of Done has another such list.

• Michael "Braidy Tester" Hunter's You Are Not Done Yet: Developer Edition offers a tester's list of things a developer might forget to test.

Does your team have a working agreement of what Done means?