Software Development Best Practices Blog

Feedback from Stakeholders – A “Done” Criterion

Each of the previous “done” criterion had the need for the individual applying the criterion to make a judgment call as to the “doneness” of the work item under review. This gives it the power necessary to determine “done” in contextual situations. However, if a person only used one of the criterion—Sufficient to Proceed, Appropriate for the Environment, or Sanity Checks—that check alone can not give a good assessment of “done”. Together they have the ability to guide the “done” decision. To confirm...

  1. Posted on December 17, 2008 7:59:AM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, humor, context, requirements, done, Management

Sanity Checks – A “Done” Criterion

For every work artifact we create there is often a short list of attributes or questions that can help us determine if the artifact is done. This short list reminds us of classic patterns that have risen to become accepted truth and classic mistakes that continue to dog us. This list of questions or attributes is what I call a Sanity Check, a quick look to see if the work artifact done. For example, if I am remolding a kitchen, the question, “Does the stove, sink, and...

  1. Posted on December 5, 2008 12:54:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, humor, context, done, Management

Appropriate for the Environment – A “Done” Criterion

When we create a work artifact on software project, we usually create it with the understanding that somebody else will need to use it. The who, when, and where of that somebody has a huge impact on whether or we can consider our work “done” or not. To be done, we must determine if the work is Appropriate for the Environment in which it will be used. Think of two teams: Team A and Team B. Surprisingly, both are working on the exact same product, using the same...

  1. Posted on October 31, 2008 12:06:PM by Earl Beede to Practicing Earl
  2. context, done, Management

Sufficiently Complete - A "Done" Criterion

A helpful way to think about a software project is to see the project as a series of decisions about what problem or opportunity the software will solve/implement and the solution itself. Theoretically the decisions start out large and granular and get refined and detailed as the project progresses. Code becomes that last place to make decisions before turning it over to the compiler. Of course in reality, software projects are more likely to see almost random decisions made at multiple...

  1. Posted on October 10, 2008 8:27:AM by Earl Beede to Practicing Earl
  2. context, done, Management

Defining 'Done'

In software development, like many other areas of life, we need to decide when some item of work is done. The decision of "doneness" has wide impacts as under-done creates defects, downstream rework, and lost opportunity costs while over-done wastes time and resource and incurs its own lost opportunities. To be even more critical, in my review of documents from hundreds of clients I find that work items are often under-done in important areas and over-done in trivial ones. That is,...

  1. Posted on September 8, 2008 1:32:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, humor, quality, done