"A user story is done when the code is fully integrated, all tests pass and the functionality meets the expectations of the story author(s)."
The Agile community calls the above statement a Definition of Done.
Such a definition becomes a working agreement in a community.
It clarifies the responsibilities of story authors and implementors.
It encourages people to be clear about the scope of work.
It helps visualize done on posters and/or electronic tools.
It aids in tracking how many stories are done or unfinished.
The Definition of Done helps with all of the above.
It has earned its reputation for being useful.
Yet we can now see some genuine areas for improvement.
We aren’t done with the Definition of Done.
Problems with the Definition
The Definition of Done is more interested in:
- Software creators (product owners, developers, etc.) rather than software users.
- Gaining acceptance internally (e.g. from product owners) rather than from end users.
- Demonstrating working software rather than producing user results in production.
- Integrating into a build rather than releasing to production.
- Tracking done work rather than discovering user needs.
- Improving the process (e.g. increasing story throughput) rather than improving the product.
- Doing rather than learning.
The Definition of Done mismanages risks by delaying contact with end users.
For example, you may internally build and demonstrate “done” software to product owners at the end of an iteration, yet by not deploying the software you may come to discover that your “done” software doesn’t behave correctly in production.
And once it gets to production, if users don’t like or don’t use the software that your product owner considered done, is it really done?
I hope not!
The sooner you get to production and learn from real users, the faster you will eliminate risks.
What Do You Mean?
Sure, that works, yet does it help us get to happy, productive users faster?
What if we build software that isn’t used, has feature bloat or poor usability?
The race to get work done, especially to show management that we got work done is far less important than focusing on creating happy, productive users.
A revised Definition of Done will help us with that focus.
A New Definition
Eric Ries, leader of the Lean Startup movement, inspires us to rapidly discover and create what users really need.
Eric talks about “ferocious customer-centric rapid iteration” using practices like:
It is no surprise that his definition of done is decidedly different from the traditional Agile version.
Here’s how I interpret his definition, based on his writings and interviews:
A story isn't done until it is being used by real users in production and has been validated to be a useful part of a product.
Including end users in the Definition of Done profoundly changes our collaboration boundary.
It asks story authors and implementors to closely collaborate with users to produce great results, rather than just get stories done.
Tracking “done” without involving end users sounds quite primitive now, doesn’t it?
Maybe it is time for you to redefine your Definition of Done?
