Definition of Done in Agile Development

Posted: August 25, 2010 in Uncategorized

One slightly peculiar question that
comes up over and over again with new Scrum teams is: what is the
definition of done? And, how do we determine what our team definition
of done is?

It is a peculiar question, because if we weren’t practicing Scrum
the answer would be obvious. In fact, the Lean and Extreme Programming
communities more or less agree on what “done” means without any real
discussion: Done == deployed in production, in the hands of real

When Scrum folks talk about the “Definition of Done,” however, they
mean something slightly different. There is an important assumption
here: software can reach an intermediate state called “done” where it
is not yet “released,” but is “potentially shippable.”

Potentially shippable is an equally peculiar idea. In theory it
ought to mean that to release or not to release is purely a business
decision at this point. The software is complete, accepted, and tested,
but it is not released. In practice it often means that the main
development activities have been completed but there is some amount of
intangible work to be done that may or may not fit inside of a Sprint
(e.g. QA testing, deployment to various environments, formal release
process, etc.) This is a poor, but common, way to address the
“Definition of Done.”

Potentially shippable software is actually a useful idea. From a
technical excellence point of view the goal should be continuous
delivery, but from a business perspective continuous delivery might not
be feasible. In fact, in some domains big-bang delivery actually has
inherent value (e.g. any COTS, especially commercial games, and various
forms of online media.) [actually, even in those environments
continuous delivery is useful, but only after the initial release hits
its date…] What we want is for continuous delivery to be attainable,
so that it becomes a business decision not to do it. Thus, XP has long
had the concept of always releasable software.

So, how do Scrum teams define done? I suppose the real answer is,
however they want to, but I suggest the following: Start with
everything that it would take to release the software to production.
Then, to the extent that it is infeasible to do all that stuff, scale
back to something that can be accomplished within a Sprint. Then,
continuously improve (i.e. inspect and adapt) until the definition is
once again everything that it would take to release the software to

By Adam Sroka


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