In Agile Software Development environments, we aim to deliver ‘[potentially] shippable code’ at the end of each iteration.

In actual fact, we often settle for delivering a chunk of value at the end of each iteration.  This ‘value’ may or may not be directly attached to a piece of shippable code. 

We also aim to close each iteration with no leftovers, no dependencies – everything must be ‘done’.

I recently watched a Google Tech Talk by Jeff Sutherland where he discusses ‘Done’ (Scrum Tuning: Lessons Learned at Google). 

Jeff explained that ‘Done’ at Patient Keeper, his company, is a piece of code live to the public having received no complaints within an hour of release.  

This got me thinking.

• So, what is ’Done’?… 
• Does ‘Done’ HAVE to be ‘live with no complaints within an hour of release’?…
• Does ‘Done’ HAVE to be potentially shippable code?
• What does ‘potentially shippable’ mean?
• Does ‘Done’ HAVE to relate to the delivery of code?
• Can ‘Done’ change one a case by case basis? …

In traditional, Waterfall, environments, we follow a series of consecutive steps running between project inception and completion – we understand that we are ‘done’ when all of the steps are complete, the product is released, we disassemble the project team etc.  This is a relatively simple concept to get your head around.

In an Agile environment, however,  we follow these steps each iteration… in fact, we probably follow these steps a number of times per day.

Of course we’re interested in being ‘done’ with the project, but we’re more interested in being ‘done’ with each task, each story and ultimately each deliverable that will in turn deliver value.

So, now we need to define ‘value’! Is value *only* delivered by shipped code? Probably not.

For example, the objective of a Spike is to get a clear idea on where to go next.  ‘Done’ in this situation might be a working prototype that might end up being released – if you’re lucky.

On the other hand, the task(s) could be to deliver a series of findings that inform a decision - ‘Done’ might be a firm decision one way or another e.g. completion of the Planning and Analysis stages.. (see inset image)

As mentioned above, you may decide not to release at the end of each iteration. You may schedule releases around Minimum Marketable Features or Epics that span multiple sprints. In these cases ‘Done’ may relate to the delivery of ‘potentially shippable’ code, which has been fully-tested, acceptance tested and performance optimised (as much as possible).

So, it becomes clear that the definition of ‘Done’ may indeed neeed to vary on a case by case basis.

With that said, regardless of what your definition of ‘Done’ is, the definition must be understood by everyone involved.

Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!