The Definition of Done (An Outline)

This post is just a brain-dump of an idea for an outline or framework for creating a Definition of Done.  Many will recognize the term Definition of Done from the Scrum process, which we use in my work.  However, this idea actually stems from my home life, where things just aren’t getting done!  As an example, when we ask for the dishes to be washed — that is exactly what happens, and nothing more.  But “doing the dishes” can include so much more:

  • Move dirty dishes out of the sink
  • Clean out the sink
  • Move things out of the drying area
  • Put down a towel for drying
  • Get a clean rag
  • Fill the sink, add dish soap
  • Soak dishes as necessary
  • Wash
  • Rinse
  • Dry
  • Put away
  • Wipe counters
  • Clean out the sink
  • Take dirty rag/towel to the laundry

The Outline:

  1. Preparation Tasks
  2. The Primary Task
    1. Subtasks
  3. Mini-tasks and follow-up tasks
  4. Maintenance Tasks

 

Preparation Tasks (and Rabbit Trails):

Preparation Tasks are things that have to happen before you can even think about completing the primary task.  As an example, the other day my wife asked me to wash the laundry.  Two important pieces of background information:

  • We had major pipe bursts over this winter and I am nearing the end of a project to completely re-plumb my house with PEX.
  • I got a new compound miter saw for Christmas which had yet to be properly setup.

I had purchased a new washer hookup box and wanted to get it installed before I ran the washer again, since I had reused the old crusty valves and push connectors — not a long-term solution.  So considering my constraints, the day went like this:

  • In order to do the laundry, I have to install the new washer hookup box.
  • In order to install the box, I need to cut a 2×4.
  • In order to cut the 2×4, I need to adjust my new saw.
  • In order to adjust the saw, I had to read the manual.

So i grabbed the manual, sat down in my chair and started reading — and promptly forgot why I had even started this whole rabbit trail.

The point is this:  when estimating a project, don’t forget all things that have to be done before the thing can be done.  A few examples in software include:

  • Installing/upgrading your IDE, Frameworks, Server software, Testing infrastructure, etc…
  • Learning a new API or library.
  • Connecting to the source control repository and downloading code.
  • For legacy project maintenance, fixing (or creating) builds that haven’t run for several coons’ age.

The Primary Tasks and Subtasks

I’m not going to spend much time here — this is the bit that we naturally focus on so volumes have been written.  Exactly how you break-down what is a primary task and its subtasks will be very subjective and it is not my intention to opine here.  Suffice it to say the Primary Task is the thing the user (or your wife) asked you to do.

Mini-tasks and Follow-up Tasks

When I say mini-tasks I’m thinking of all the side things that just need to be done to get to “fit and finish”.  The example in the case of dishes is cleaning the counters.  It’s not technically “washing dishes”, but the job just wouldn’t be done without it — this is the bit my kids like to skip (or argue with lawyerly vigor was not a part of the contractual negotiations that apparently happened while I was sleeping).

Follow-up tasks might include putting away tools, cleaning up the workspace.

Maintenance Tasks

Maintenance tasks (as contrasted with Follow-up Tasks) make me think of things like sharpening the chain on the chain saw so that it’s ready for the next time it’s used.  A few other examples I can think of:

  • Start the clothes washer after gathering the dirty rags and dish towels.
  • Refilling the jet-dry dispenser
  • Organizing tools

For the case of software development, I’ll state 2 major counter-examples that I DO NOT consider “Maintenance Tasks” or Follow-up Tasks:

  1. Unit Testing
  2. Refactoring

To me these are an integral part of the Primary Task (or at worst Subtasks).