The magic of "Definition of Done" and "Task List"

Sunday, October 5th 2014, 4:21 pm

I have often heard my friends say that a programmer is a person that can turn coffee into working software. This line is not only funny, but it is also indicative of the mystery that surrounds software development. If you ask around, you quickly realize that most people feel there is something magical about how ideas are transformed —through some quick typing in a computer— into a set of icons and buttons in a screen that do something when pressed.

This feeling of magic is the result of the traditional method of developing software: if someone, let's name him Bob, were to require some sort of software, Bob would first give a list of requirements for the software to a team of programmers; the team of programmers would in turn, hide in a cave for a few months and return later with fully functioning software. How the software was created is anyone's guess.

The downside to this process, is that the software that comes out of the cave is not the software that Bob wanted (being in a cave for a few months is not so good for communication, although it is good for creating an impression of magic). A group of programmers recognized this problem and in 2001 created the Agile Manifesto, a set of principles that promised better software through better communication with Bob, the customer. Agile proved to be very popular and is now the way in which most teams develop software (West, 2011). Let me now pull the curtains back and show you how software is made from the point of view of Agile. I will do this by explaining two important concepts: Definition of Done and Task List (the traditional way of developing software will remain a mystery though).

A picture of a software cave

Baker, S., Buzz in the Bullpen. [Picture]. (2008) Retrieved Oct 5, 2014 from:

In Agile, Definition of Done refers to a checklist of different goals that must be met before a piece of software can be declared finished. This Definition of Done is not predetermined by someone, but is instead the result of dialogue between the stakeholders of a project: a representative of Bob (which in Agile is called a Product Owner), and the development team. The reason that the Definition of Done gives insight into the development process is that it gives a place for the goals that are internal to the software development process to be stated. Goals like: "the code must have 90% of test coverage", and "there must be automatic builds of the code", are often included in the Definition of Done. These goals are important because they represent what the team must do to quickly produce bug-free code. Through examining the Definition of Done, we are privy to the process that the development team is following in order to produce good software.

The second important concept is the Task List. The Task List represents a detailed list of the steps that the development team will need to follow in order to implement one of the features that Bob wants in the finished software. The team will only create the Task List for features that the team intends to develop in the next iteration of their software development cycle or Sprint (for a deeper explanation of what a Sprint is read my previous post). Each of the tasks that are listed is fairly specific, ideally one task should represent a step that can be completed by a single person in a short time, like a single day ("complete the software" is not a good task, for example). A Task List removes the magic behind building software because it forces the team to document what they will do in order to write the code.

You may be tempted to think that the Definition of Done and the Task List represent a lot of work for the sake of bureaucracy. This is not so, as a matter of fact a study by Sutherland, Downey and Granvik (2009) showed that teams that adhere strictly to these concepts could be as much as 800% more productive. Strict adherence to Agile principles — including the Definition of Done and the Task List — is important as teams that do not follow the principles as closely are much less productive. This is exemplified in the chart below, which plots the efficiency gains of teams which adopted Agile in MySpace. The teams that did not adopt Agile fully represent the low points, while teams that adopted Agile had the most productivity gains.

A graph showing the velocity of MySpace teams by sprint

Sutherland, J., Downey, S., Granvik, B., (2009) Velocity of MySpace Teams by Sprint [Figure] In Shock Therapy: A Bootstrap for Hyper-Productive Scrum (p. 72)

The next time that you are wondering how a particular Agile team is turning coffee into software, go ahead and ask them if you can take a look at their Task List and Definition of Done. You will be surprised by the amount of effort that needs to be added to coffee in order to make software a reality.


  1. Sutherland, J., Downey, S., Granvik, B., (2009) "Shock Therapy: A Bootstrap for Hyper-Productive Scrum," Agile Conference, 2009. AGILE '09 (69-73) doi: 10.1109/AGILE.2009.28
  2. West, D., (2011) "Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today" Forrester Research
comments powered byDisqus