Defining “Done”

Introduction

A common definition for work done is, “I am sure this will be OK,” and “The deadline is up.”

If a team applies one of these definitions to requirements, test plans or code, then defects slip downstream, causing rework, extra test cycles, costs and upset customers.

Here is an alternative definition for “done”:

• The work has been inspected for defects (errors and omissions)
• Defects have been repaired and verified
• Code has passed its test cases
• The final document or code is under configuration management (versioned and backed up)

A solid definition of “done” helps a team avoid chaos and minimize rework. It also enables schedules to be meaniful and reliable. “Done” is a fundamental characteristic of a professional environment that is fun to work in.

When I work with a client on quality issues (or “done”), we often perform a sample inspection (team peer review) on work that has been declared “done.” Ninety percent of the time we can still find:

• Between 1 and 4 critical or major defects per page for documents (e.g., requirements, backlogs, and test plans)
• Between 37 and 44 critical or major defects per Thousand Lines of Non-commented Source Code (KLOC), depending on the age of the code.

Critical code defects include memory leaks, incorrect variable names, logic errors, and wrong path names. These defects are difficult to find in test and drain the team of resources after release if not caught.

Who is involved, and how fast are these inspections (team peer reviews)?

Inspections are conducted by the team and avoid evaluating the author. When inspections are conducted efficiently, a team of three to five people logs between one and two defects per meeting-minute. So in 30 minutes, 30 to 60 defects are logged. Compare these numbers to the reviews you conduct now.

Conclusion

Defining “done” enables schedules to be meaningful and work to be reliable. It only takes a fraction of the project’s budget to find the majority of defects upstream, and the time invested saves numerous expensive test and rework cycles later.

What is your team’s definition of “done,” how should it change, and what would be the impact?

 

---

 

If you have comments or questions about this article, or would like to get some helpful complimentary feedback regarding your “done” and quality challenges, contact us.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link.

If there are challenges your group is having that you would like us to anonymously address in future blogs, let us know.

Other articles you might like:

• https://processgroup.com/does-quality-matter/
• https://processgroup.com/developing-critical-systems-is-testing-enough/

We would love your feedback

Fill out our five-question survey and tell us what you think.