Agile 101

Project Management, Digital Publishing and Agile Software Development

What does 'Done' mean in Agile Software Development?

Posted by Tara Hamilton-Whitaker on September 4, 2009


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 Agile101 RSS to be notified when I upload new Articles, Videos, Templates and Tips!


3 Responses to “What does 'Done' mean in Agile Software Development?”

  1. Done, to me, means when the current features are completed and live and the customer is no longer willing to pay for new features.

  2. Nice, I like it. Personally I go with the concept of a “done list” stuck up somewhere defining what it means for the team to be “done” or done done as they say. You might be interested in this as well:

  3. The done term can certainly refer if one task set up to finish in a scheduled duration is finished and no more things related to it are pending. We can go for the next iteration following this up.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: